| Email Deliverability Conversations - What's in a bounce? | 02:06 |
|
nhận xét (0)
Filed under:
bounce email,
email deliverability
|
|
Yesterday, a friend found a terrible post about bounces. We talk about looking at your bounces and understanding what they mean in regards to your list health, but what are bounces and why should you care?
There are a few types of bounces. The two main types are hard bounces and soft bounces. Bounces are based off the SMTP reply codes that we receive back from your recipients' mail servers. When we get the reply code, we bucket that response into a category. Our bounce processing actually goes a bit farther than just looking at the SMTP response code and examines the text of the response for key words to make sure that we're putting the bounce in the right bucket.
Hard bounces are when the email that you sent will never be delivered. These are typically the 5xx series codes, such as Invalid users. If the email address does not exist, you will see that show up as a hard bounce. The receiving mail server just told us we're not going to be able to send that email to them. Sometimes this just means that the mailbox is full so we should try again with the next send. Those have different numbers for the xxs. If the mailbox doesn't exist, we don't try again with the next email you send. If the mailbox if full, we do. Some spamblocks show up as 5xx. AOL's most common blocks are 5xx.
Soft bounces are when the email that you sent cannot be delivered right now, but we should keep trying for up to 72 hours. These are typically the 4xx series codes, such as Service unavailable. This may mean that the receiving mail server is currently overwhelmed or the mailbox is currently unavailable. Some spamblocks show up as 4xx. Yahoo's most common blocks are 4xx.
When a bounce is processed after the SMTP transaction, that is called a Non-Delivery Report (NDR) or Delivery Status Notification (DSN). These can also be hard or soft bounces based on the SMTP code. The only difference is that they do not occur immediately during the send.
A well-maintained list should have fewer than 2% total bounces, but most ISPs don't tend to get twitchy until you have more than 10% bounces. Bounces of more than 10% indicate an old list or blocking problems. You should always see more hard bounces than soft bounces. If you see more soft bounces, then you're probably seeing blocking.
It is possible, even on very large lists, to have bounces under 0.5% on a regular basis but you need to be willing to clean the dead wood out of your list. When you do that, you're also cleaning out the people who aren't responding and interacting with you. It's that kind of list maintainence that gets you into the inbox and keeps you there.
| SMTP error messages | 01:41 |
|
|
|
421 Connection timeout
If there is a timeout while hMailServer is waiting for a command from the SMTP client, this error message is sent to the client before hMailServer disconnects the client. The SMTP timeout in hMailServer is 10 minutes.421 Excessive amounts of data sent to server.
This error is generated by hMailServer if a client sends a large chunk of data to hMailServer not containing a newline character (command terminator). A client should never do this, but incorrectly configured clients could cause this problem.451 Please try again later.
This error message is issued if grey listing is enabled, and the sender, recipient and IP address triplet does not match an existing greylisting triplet.500 Line too long
If a SMTP client sends a SMTP command which hMailServer considers beeing too long, hMailServer issues this error. This error typically indicates a client defect or a hacking attempt.501 EHLO Invalid domain address.
This error message is issued if the domain address given in the EHLO command does not have the correct syntax.501 HELO Invalid domain address.
This error message is issued if the domain address given in the HELO command does not have the correct syntax.502 TURN disallowed
If a SMTP client tries to use the TURN command hMailServer responds with this error code. hMailServer does not include support for the TURN verb.502 Unimplemented command
If a SMTP client tries to use a command which hMailServer has no implementation for, this error message is sent to the client.502 Use HELO/EHLO first
After a SMTP client has connected to a SMTP server, the first thing it should do is to identify itself using the HELO or EHLO command. If the client does not do this, hMailServer responds with this error message.502 VRFY disallowed
If a SMTP client tries to use the command VRFY, hMailServer responds with this error code. hMailServer does not include support for the VRFY verb.503 Issue a reset if you want to start over
When an email client delivers an email message to an email server, it starts of by telling the server the senders address. After it has done this, a transaction is started which is not finished before the entire message has been delivered to the email server. If the client wishes to abort the transaction and send another message, it should issue the RSET command. If a client, in the middle of a transaction, tries to send a new email without first aborting the current transaction, hMailServer issues this error message. This indicates a bug in the SMTP client.503 Must have sender and recipient first.
When a SMTP client is delivering an email to a SMTP server, it must specify both the sender and recipient before trying to submit the actual message content. If a client fails to tell hMailServer the senders or recipients address prior to trying to submit the message content, hMailServer will respond with this error. This indicates a bug in the SMTP client.503 Must have sender first.
When a SMTP client is delivering an email to a SMTP server, it must specify both the sender and recipient before trying to submit the actual message content. The client must first tell the server the sender address and after that the recipient address. If the client tries to tell hMailServer the recipient address before the sender address, this error message is issued. This indicates a bug in the SMTP client.504 Authentication mechanism not supported.
This error message is issued if a client tries to authenticate using a method which is not supported by hMailServer.504 Authentication type not specified.
This error message is issued by hMailServer if a client tries to authenticate without specifying authentication method. This error indicates a bug in the used SMTP client.530 SMTP authentication is required.
You have enabled SMTP authentication for the IP range that the user is connecting from, but the user has not configured his client to use SMTP authentication. There's two ways to solve this problem. Either configure your email client to use SMTP authentication. This setting is normally found in the account settings in your email client. Or, disable SMTP authentication for the IP range. The first solution is recommended since it reduces the risk that anyone will send spam through your server.By default, hMailServer does not require SMTP authentication for connections coming from localhost / 127.0.0.1. For connections coming from other hosts, SMTP authentication is required for deliveries to external recipients. By default, hMailServer never requires SMTP authentication for deliveries to local accounts, since that would prevent other e-mail servers to deliver email to your installation. For information on how to enable SMTP authentication, check the HOWTO.
If you are using a Cisco router, you may need to disable SMTP Fixup protocol. If this is enabled, the router will sometimes intercept SMTP traffic and replace data in it before it reaches hMailServer which will cause problems.
535 Authentication failed. Restarting authentication process.
If a SMTP client authenticates but the username or password is incorrect, or the account is disabled, hMailServer sends this error message to the client.550 A valid address is required
hMailServer issues this error message if a SMTP client tries to specify a recipient address which is not valid (which has an incorrect syntax).550 Account is not active.
If a SMTP client tries to send an email message to an account which is not enabled, this error message is given to the client.550 Alias is not active.
If a SMTP client tries to send an email message to an alias which is not enabled, this error message is given to the client.550 Blocked by SPF
If an email message is rejected during SPF checks, this error message is issued.550 Delivery is not allowed to this address
This error means that the sender is trying to send an email to an address which he is not allowed to send to. This message is generated after hMailServer has checked the IP range settings. As an example, the default IP range configuration does not allow external users to send messages to other external users. This is to prevent people from using your server to send spam. So if an external user tries to send a message to another external user, he will get this message.550 Distribution list is not active.
If a SMTP client tries to send an email message to a distribution list which is not enabled, this error message is given to the client.550 Domain has been disabled.
If a SMTP client tries to send an email message to a domain which has been disabled, this error message is given to the client.550 Invalid syntax. Syntax should be MAIL FROM:<userdomain>[crlf]
If a client issues a MAIL FROM command with an incorrect syntax, hMailServer issues this error message.550 Login credentials no longer valid. Please re-authenticate.
During a SMTP session, a SMTP sender can send multiple email messages. Each time a SMTP client tries to deliver a new message to hMailServer, the client is re-authenticated to ensure that the username and password is still valid. This is needed since there is no limitation on how long a SMTP client may stay connected to hMailServer as long as it is sending messages. If hMailServer did not re-authenticate connected users, there would be no way to disconnect a user which were sending spam (without stopping the.550 Mail server configuration error. Too many recursive forwards.
When an email client tells hMailServer who the email message is for, hMailServer tries to determine the "end recipient". The email address the client has given hMailServer may not be the end recipient. For example, if you have set up an alias, alias@example.com which points at account@example.com, and the email client tells hMailServer that the message is for alias@example.com, the end recipient is actually account@example.com.It is possible to configure hMailServer in an incorrect way in this area. For example, say you have an alias named alias@example.com pointing at alias2@example.com, and the alias alias2@example.com is pointing at alias@example.com. When hMailServer is trying to determine the end recipient for an email to alias@example.com, it will give up since there is none and report the above error message. The error will always be reported if hMailServer can not determine the end recipient.
The following causes are the most common ones:
- A catch-all address has been specified for the recipient domain, but no account exists which matches the specified catch-all address.
- The message is being sent to an alias which does not point at a valid account
550 Not authorized.
If a client tries to send an email message to a distribution list which it has not permission to send to, this error message is issued.550 Recipient not in route list.
If a client tries to send an email message where the recipient domain matches a route, but the recipient address is not in the list of valid addresses, this error message is given to the client.550 Sender address must be specified.
If hMailServer is configured to reject empty sender addresses, and a SMTP client tries to use an empty sender address, this error is issued.550 Sender domain does not have any MX records.
If an email message is rejected due to the MX check, this error message is issued.550 The address is not valid.
hMailServer issues this error message if a SMTP client specifies a sender address which is not valid (which has an incorrect syntax).550 The host name specified in HELO does not match IP address.
This error message is a part of the spam protection mechanism in hMailServer. When a sending email server delivers an email message to hMailServer, one of the first things it needs to do is to identify itself. It does this by sending the command HELO <HOSTNAME> where <HOSTNAME> is replaced with its host name. The host name the sending server gives in the HELO command should resolve to the IP address of the same server.For example, if one of Hotmails servers tries to deliver an email to your server, it will send a command similar to HELO mx1.hotmail.com. If the option Check host in the HELO command has been enabled in the spam protection settings in hMailServer, hMailServer will check that the host name Hotmails server sent, mx1.hotmail.com, matches the IP address the connection is being made from. If the IP address does not match the host name, hMailServer considers the email message to be spam. If you have configured hMailServer to delete e-mail which is considered spam, hMailServer will report the above error message to the sender.
If someone tries to send you an email and you they get this error, take one of the following actions:
- Notify the administrator of the server sending the email that they have not specified the correct host name in the HELO command.
- Disable the "Check host in the HELO command" option in the spam protection settings using hMailServer Administrator or PHPWebAdmin. This option is disabled by default.
- In the spam protection settings, select that hMailServer should deliver spam messages, but modify the message headers. Also select to modify the message subject. Then the email will be delivered, but the subject will be prepended with [SPAM].
550 Unknown user
This error message is issued if the SMTP client tries to deliver an email to a domain hosted by hMailServer but the recipient account cannot be found and no catch-all address has been specified for the recipient domain.550 <Other error message>
In DNS blacklist and SURBL configuration, it is possible to specify custom error messages to be used when an email message is being rejected.552 Message size exceeds fixed maximum message size. Size: x KB, Max size: y KB
In hMailServer it's possible to specify a maximum message size in the SMTP settings and in the domain settings. If a message is sent which has a size which exceeds these limits, this error message is issued.554 Rejected
If a hMailServer script running on the OnAcceptMessage event rejects a message without specifying an error message, this error is issued.554 Your message was received but it could not be saved. Please retry later.
If the email message was received by hMailServer but could not be saved in the database, this error message is sent to the client. To resolve this issue, the hMailServer logs leading up to the error needs to be analyzed. Normally an error message with more details will be logged when this error is reported to the client.554 Rejected - Message containing bare LF's.
According to the SMTP specification, every line in an email message should be separated by the ASCII-codes 13 and 10 - carriage return (CR) and line feed (LF). Some spammers and incorrectly working software sends messages which are not correctly formatted. Use this setting to reject these messages. Please note that legitimate email might have incorrectly formatted line endings, if the sending software contains bugs.If you who are a developer receive this problem, confirm that each line of your email message (both header and body) is ended with a carriage return and a line feed, and not just a line feed. How to do this depends on what programming language you are working with. In .C++, C#, and PHP add \r\n to the end of every line. In Visual Basic, add vbNewLine or vbCRLF.
On Windows, the default line separator is CRLF. On Linux and UNIX, the default separator is only LF. However, when sending an email message from a Linux/UNIX system, CRLF must always be used. Some email servers under Linux (such as Postfix) automatically replaces LF with CRLF. Hence, setting the line separator in the email to CRLF will cause it to be changed to CRCRLF.
554 Rejected - No data saved.
If hMailServer received an email message from a SMTP client but could not save the message file on disk, this error message is issued. The problem will occur if the data directory specified in hMailServer.ini is not writeable by the hMailServer service.554 Rejected - <other error message>
When a hMailServer script rejects a message in the OnAcceptMessage event, it can specify an error message to be sent to the client. If a script does this, hMailServer sends this error message to the client. <Other error message> is replaced with the error message given by the script.554 Tagged as Spam by SpamAssassin
If an email message is rejected by SpamAssassin, this error message is issued.Error messages in bounce messages
The mail server software tried to deliver e-mail to the local machine
This error message typically indicates a server configuration error. hMailServer does a number of checks before message delivery to prevent infinite message looping. When an email is sent and the recipient can not be found in the local installation, hMailServer will normally try to connect to the recipients email server to deliver the email message.Before hMailServer connects to the recipients email server, hMailServer checks that the IP it is going to connect to is not a local IP address. If the IP is a local IP address, this would mean that hMailServer would connect to itself, which would likely cause a message loop. In this case, hMailServer rejects the message delivery and returns an error message to the sender instead.
The following causes are common for this problem:
- A host name or IP address which points at the local computer has been entered as SMTP relayer. Go to the Delivery of e-mail section in the SMTP settings. Check the SMTP Relayer setting. If you have entered localhost, 127.0.0.1, your-own-domain-name.com, or something similar in this textbox, this is likely the cause of the problem. If this is the case, read more about this setting in the SMTP reference guide, and then correct it.
- One of the MX records for the domain points at your server, but the domain has not been added to your installation.
No mail servers exists for the address.
When hMailServer delivers an email to an external recipient, it does a DNS query to determine where the email message should be delivered. If this DNS query fails, the above error message is reported. For example, the query may fail if the DNS server is unavailable or if the recipient domain does not exist. For further troubleshooting, check the hMailServer error log. The hMailServer error log will contain error codes from the DNS-client in Windows.Error messages not generated by hMailServer
550 Mailbox unavailable
hMailServer never generates this error message. If hMailServer is trying to deliver an email message to another server, but the recipient account cannot be found on that server, the recipients server may issue this error message.The error message indicates that you are sending the email to an incorrect address. If you are sure that the address is correct, it may be a problem in the recipients DNS configuration.
550 Sender verification failed
When hMailServer deliver an email to another server, the receiving SMTP server may try to validate that the email sender really exist. If this verification fails, it may respond with the error message 'Sender verification failed'. In these cases, the email will be bounced back to the sender. This verification works the following way:- hMailServer connects to the recipients SMTP server
- hMailServer tells the recipients SMTP server that the email is from example@example.com
- The recipients SMTP server looks up a MX record for the domain example.com.
- The recipients SMTP server connects to the host specified in the MX record - which is likely where your hMailServer server is running if the MX records are set up properly.
- After this, the recipients SMTP server issues the commands HELO, MAIL FROM<> and RCPT TO:
- If hMailServer confirms that the recipient example@example.com exist, the recipients SMTP server will allow the delivery initiated in step 2 above.
- If the MX records for the domain example.com is not set up properly, the recipients SMTP server may correct to an incorrect SMTP host and the sender address verification will fail.
- If the account example@example.com does not exist, the sender verification will fail.
- If you have disabled Allow empty sender address, the sender verification will fail, since the recipients SMTP server tries to verify by using an empty sender address.
In: http://www.hmailserver.com/
| Email marketing Messeage Bounce Back - What the SMTP Error Code Means | 01:33 |
|
|
|
When you send your email marketing messages, are you ever alarmed by SMTP error codes?
What are these email error codes and what do they mean? Should it be a cause for alarm or can it be addressed by a simple quick fix?
Before panic sets in, first let’s understand these codes and what they mean to your email marketing program. Otherwise known as Simple Mail Transfer Protocol, SMTP is in charge of sending out your email messages. So an SMTP error code basically means that your email did not get to the recipient. Keep in mind, not all SMTP codes are error codes. However, the “sent codes” are rarely ever seen, and the codes that you receive in your bounce back message generally indicate an error.
SMTP codes usually consist of three digits that carry different meanings. The digits specify what has gone wrong, in other words each digit gives some form of diagnosis to the email sending failure that happened.
The first digit indicates if the command was established and processed. However, there are five different values for the first digit, which includes (1) Command accepted by mail server but confirmation message is required, (2) Task was completed without errors, (3) Mail server accepted the request but requires more information, (4) Temporary failure encountered by mail server and you have to try again, and (5) Fatal error encountered, Mail server cannot process request. You will most likely encounter error digits (4) and (5).
Meanwhile, the second digit can mean syntax errors, status of connection, mail server status or information reply. The third digit of the SMTP error code contains the details of the status of the mail transfer.
Common SMTP Codes
Let’s take a look at the most helpful SMTP codes that indicate the status of your messages:211 – System status message or system help reply
220 – The SMTP Service is ready
250 – Requested action accepted and completed
251 – The user is not local to the server but will forward the message anyway
252 – Recipient not verified but mail server attempts delivery
354 – Indicates mail server is ready to take message or start mail input and end with a dot
However, the SMTP codes that you really want to pay attention to are the error codes, and here are the most common:
421 – Service not available, closing transmission channel and service to shut down
450 – Mailbox busy or unavailable, thus requested mail action was not taken
451 – Server error, requested action aborted
452 – Insufficient system storage, requested action aborted
500 – Command unrecognized due to syntax error
501 – Syntax error in parameters or arguments
502 – Command not implemented
503 – Mail server encountered bad sequence of commands
504 – Command parameter not implemented
550 – Mailbox unavailable, requested action aborted
551 - User not local to server
552 - Storage allocation exceeded, requested mail action aborted
553 – Mailbox name invalid, requested action aborted
554 – Transaction failed
While these error codes are the most common, the ones you’ll encounter the most often are those with the 55-digit range, the most common of which is the 550 SMTP error code. The 550 code is usually generated when you’ve sent your message to an improper email address, and simply double checking the email address and resending the message will fix the problem.
If you’re doing any type of email marketing, SMTP error codes are not something to take lightly. If you consistently send messages that are getting bounce back, the receiving internet service provider – in other words, where your email is getting sent – could decide to blacklist your own email address or IP address. This could prevent all of your future email messages to that ISP, even those sent to other addresses, from getting delivered.
SMTP error codes can give you excellent insight into the technicalities of your email marketing program. Unfortunately, most marketers ignore them. By paying attention to your bounce back messages, you can usually catch mistakes and fix them, before you end up on an email blacklist.
http://www.modernimage.com
| Reading message contents email | 00:57 |
|
|
|
int imap_num_msg ( resource imap_stream)
string imap_body ( resource imap_stream, int msg_number, int options)
To get the number of messages in a mail box, pass your IMAP stream into imap_num_msg() and store the return value, like this:
<?php
$imap = imap_open("{mail.yourserver.com:143}INBOX", "username", "password");
$message_count = imap_num_msg($imap);
print $message_count;
imap_close($imap); ?> On 22nd April 2004, FooBar <foo@bar.com> said, "first 100 characters of message here".\n - Open mail box, get number of messages
- For 0 to number of messages, get header and get body
- Trim body to a maximum of 100 characters
- Format message date to the format "jS F Y"
- Print out the data
Here is how it looks in PHP:
<?php
$imap = imap_open("{mail.yourserver.com:143}INBOX", "username", "password");
$message_count = imap_num_msg($imap);
for ($i = 1; $i <= $message_count; ++$i) {
$header = imap_header($imap, $i);
$body = trim(substr(imap_body($imap, $i), 0, 100));
$prettydate = date("jS F Y", $header->udate);
if (isset($header->from[0]->personal)) {
$personal = $header->from[0]->personal;
} else {
$personal = $header->from[0]->mailbox;
}
$email = "$personal <{$header->from[0]->mailbox}@{$header->from[0]->host}>";
echo "On $prettydate, $email said \"$body\".\n";
}
imap_close($imap); ?> First, our IMAP stream is opened as usual, then we grab the number of messages currently in there and store it in $message_count. This is then used as our maximum loop value - note that we count from 1 to $message_count inclusive because the IMAP sequence numbering is 1-based, which means it counts from 1 up rather than 0 up.
Next, the header information for the current message is grabbed and stored in $header, and the body text is also grabbed and placed in $body. Note that the body text is cut to 100 characters then trimmed.
The udate field in the header is our Unix date, so that is formatted to the required layout. Then comes the from[0]->personal issue - if you recall I mentioned that not everyone sends a personal name in their From header, so this field might not be set for everyone. To get around this, isset() is used to check whether the variable exists, and, if it does, it is placed into the $personal variable. If not, the sender's mail box name is used instead, which would be the "foo" in "foo@bar.com".
Finally, all the information is printed out, the loop continues until it hits the end of the mail box, then the IMAP stream is closed and the script is complete.
Now, if only 100 characters from the body is used, why is the script slow to execute? The problem is that imap_body() returns the entire body of each message, of which we use just 100 characters. So, if someone sent you a 7MB file attached to an email, imap_body() would download all of it then throw away 99% percent of it. Worse, what we do get in the meagre 1% we read is likely to be all sorts of MIME gibberish such as "----=_NextPart_000_0022_01C3EC8E.3DBDDCB0". Dealing with this involves really getting into the guts of MIME messages, so, if you think you have had enough - the script we just produced works fine for plain text messages - I suggest you stop here and skip on ahead.
Author's Note: You can pass FT_PEEK as the third parameter to imap_body() to have it not set the read flag to true for the selected message. Without this, any message retrieved using imap_body() is marked as read.
http://tuxradar.com/
Đăng ký:
Bài đăng (Atom)