Greylisting: Difference between revisions

From ASRG
Jump to navigationJump to search
(New page: {{ast |date=early 2000s |difficult=medium |popular=Low, increasing |effective=High |where=MTA }} Greylisting (AKA graylisting) is an extremely effective method against fly-by-night (i.e. ...)
 
No edit summary
Line 7: Line 7:
}}
}}


Greylisting (AKA graylisting) is an extremely effective method against fly-by-night (i.e. [[chickenbone]]) spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against so called [[mainslease]] spam.
Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conventional MTAs.


Greylisting operates by initially deferring incoming messages by giving a 451 (means: temporary error, try again later) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery (sender's IP address, [[envelope sender address]], [[envelope recipient address]]), which is called the triplet.
Greylisting operates by initially deferring incoming messages by giving a 4XX (means: temporary error, try again later) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery (sender's IP address, [[envelope sender address]], [[envelope recipient address]]), which is called the triplet.


If the new delivery attempt with the same tripled comes within the time window that the receiving MTA uses the message will be accepted. Often the triplets are stored for a while so that the next messages will get thru without delay.
If the new delivery attempt with the same triplet comes within the time window that the receiving MTA uses the message will be accepted. Often the IP addresses of successful retries are stored for a while so that later messages will get through without delay.
Other versions save triplets and only skip greylisting of messages that exactly match the triplet.


While effective against certain kinds of spam, the technique has it's drawbacks:
While effective against certain kinds of spam, the technique has its drawbacks:
<ul><li>messages are initially delayed, possibly for days</li>
* greylisted messages are initially delayed, possibly for hours or days
<li>problems with outbound server pools</li>
* problems with outbound server pools that retry with different IPs
<li>unwanted interactions with servers doing callbacks</li>
* unwanted interactions with servers doing callbacks
<li>unnecessary burden on the sending MTAs</li>
* extra burden on the sending MTAs
</ul>

Revision as of 18:20, 16 January 2008

Anti-spam technique: Greylisting
Date of first use: early 2000s
Effectiveness: High
Popularity: Low, increasing
Difficulty of implementation: medium
Where implemented: MTA
Harm: {{{harm}}}


Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conventional MTAs.

Greylisting operates by initially deferring incoming messages by giving a 4XX (means: temporary error, try again later) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery (sender's IP address, envelope sender address, envelope recipient address), which is called the triplet.

If the new delivery attempt with the same triplet comes within the time window that the receiving MTA uses the message will be accepted. Often the IP addresses of successful retries are stored for a while so that later messages will get through without delay. Other versions save triplets and only skip greylisting of messages that exactly match the triplet.

While effective against certain kinds of spam, the technique has its drawbacks:

  • greylisted messages are initially delayed, possibly for hours or days
  • problems with outbound server pools that retry with different IPs
  • unwanted interactions with servers doing callbacks
  • extra burden on the sending MTAs