An email message I sent to a Tiger Technologies customer was "greylisted". What does that mean?
If you sent a message to one of our customers, and your mail server returned it as "undeliverable" because your address is "greylisted", the mail server you're using to send your messages (which is probably run by your ISP or your company) is not working properly.
The quick solution to this problem is to resend your message from the same address. Your message will almost certainly go through if you send it again.
However, you should also report this problem to the person who runs your outgoing mail server (probably your ISP or your company network administrator). Your outgoing mail server has a technical problem that needs to be fixed to make sure the same problem doesn't happen again in the future.
The rest of this page contains technical information that may help your network administrator fix the problem.
A note to mail server administrators
If you're seeing a link to this page in your mail server logs (rather than in a "bounce" message), that's probably normal. If your mail server is properly configured, it will automatically "queue" the message and keep trying to resend it again. Our servers will accept the message after a short time has passed.
In other words, seeing a link to this page in your logs doesn't mean anything is wrong. Your mail has not been rejected; it has merely been delayed for a short time. A problem exists only if you see a link to this page in a bounce message, which would indicate your server did not retry the delivery as required by the Internet standards described below.
What is greylisting?
Greylisting is a technique that we, and many other ISPs, use to protect the mailboxes of our customers from spam.
The idea behind greylisting is that when our mail server sees a "suspicious" incoming message — one that is probably spam — it will send a "450 temporary rejection" error code to the sending mail server. The error code means "We can't accept this email message right now, but try sending again soon and we'll accept it then".
The sending mail server is required by Internet standards to try again (usually this occurs within a few minutes), and our servers will then accept the message. The person sending the message does not see a "bounce" error, and in fact has no idea that anything unusual happened.
Almost all of the messages tagged as being "suspicious" are actually spam, not personal messages, so this system has a minimal effect on normal email. But it has a great effect on spam, because the vast majority of spammers use special software that does not meet Internet standards and will not try sending the message again. The spammer's software simply deletes the spam and the recipient never sees it.
What makes a message "suspicious"?
Only "suspicious" messages are subjected to greylisting. We generally consider a message to be "suspicious" if one of the following is true:
- The sending mail server is listed in a "blocklist", such as Spamhaus.
- An SPF lookup returned a "softfail" error, indicating that the sending mail server isn't usually authorized to send messages from that address.
- The sending mail server does not appear to be a legitimate mail server. For example, a message sent directly from a computer on a cable modem or DSL connection that bypasses an ISP's normal mail server would be suspicious, as would a message sent from a computer that has generic or non-working "reverse DNS".
However, we do not consider a message to be suspicious if the sender has sent any other messages to the same recipient within the last 35 days, even if the sending mail server is on a blocklist or doesn't appear to be legitimate. This ensures that only the first message someone sends to one of our customers will be delayed, even if it looks suspicious.
Less than 1% of legitimate messages appear "suspicious" to our greylisting system. The "reject" message from our server (the one that mentions this Web page address) will probably tell you what our servers considered "suspicious" if you're interested.
What happens if the sending mail server doesn't try sending the message again?
If a sending mail server receives a 450 temporary rejection error code, it is required by Internet standards to retry sending the message. We can't emphasize this enough: any mail server that does not retry the message is not sending mail properly and will be unable to properly deliver mail to tens of millions of mailboxes on the Internet that use greylisting.
In fact, such a mail server will have all sorts of other problems delivering mail, regardless of greylisting. For example, it will be periodically unable to deliver messages to servers that temporarily reject messages when they are too busy, such as those at hotmail.com. Some tests have shown that a server that is misconfigured in this manner can find that as much as 5% of mail sent to hotmail.com is unnecessarily rejected.
Where do Internet standards say that retrying is required?
The technical explanation of why retrying is required is that RFC 2821 defines a 450 error code as a "Transient Negative Completion reply" in section 4.2.1. Then, in section 4.2.5, it specifies that if an SMTP mail server receives such a reply, it must continue "retrying delivery some reasonable number of times at intervals as specified in section 4.5.4." Finally, section 4.5.4 says "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender", and that retrying should continue for "at least 4-5 days".
So what does this all mean to me?
As you can see from the description above, "greylisting" can delay a suspicious message for a short time, but it will never reject a message or cause it to be returned as "undeliverable" — as long as the sending mail server meets Internet mail standards.
If your SMTP server sent one of our customers an email message but received a "450" error code, and your server immediately returned the message as "undeliverable" without retrying it for several days, your mail server is misconfigured. You should consult the documentation for your mail server and fix it so that when it receives a 450 error code, it retries the delivery for at least a few days, instead of immediately returning the message to the sender. This will ensure your mail server meets Internet mail standards.