The Basic Premise:
The first time a given email server receives a message from a given sender, we respond to the sending mail server with a temporary rejection message, asking the sending mail server to try again. (This happens during the SMTP conversation and is transparent to end users.) With legitimate email, the sending mail server tries again a few minutes later, at which time the receiving server would accept the message. Most spam messages are sent using software that will not retry the delivery - thus, those junk messages will never be re-sent, and will never arrive either in the GFI MailEssentials quarantine or in the user’s inbox. And, because those messages won’t be in the quarantine, the daily digest, or a user’s spam folder, greylisting can save time that would normally be spent scanning those messages.
How Greylisting Works:
For each incoming message, three elements are examined in the early part of the SMTP conversation: the IP address of the sender, the sender email address, and the recipient email address. If this is the first time this email "relationship" has been identified, a temporary deferral message is issued to the sending mail server, before the DATA portion of the email is sent. That relationship is then "greylisted." If or when within a finite period that same set of sender IP address, sender email address, and recipient email address is seen again – as would be expected with any legitimate email - that combination is "whitelisted", so that that message, as well as any future message with that relationship, is passed through without the temporary deferral. The whitelisting remains in place for upwards of a month. After a message passes through the greylisting, that message is processed as usual, so that any spam message that is retried will still be subjected to the same message analysis techniques as in cases where greylisting is not used.
Impact on Mail Flow:
The Greylist by its nature can introduce delays in initial message flow, but these delays are generally brief and non-recurring for a given recipient-sender combination. The length of the delay is dependent on how long a sending mail server waits before retrying after we defer the message. While a few sending mail servers - typically hose used for high-volume mailings - will have a relatively long retry interval of an hour or more, most mail servers will automatically resend a temporarily deferred message in 15 minutes or less. Additionally, since the email “relationship” described above (sender IP address, sender address, and recipient address) is whitelisted after a single temporary deferral, there should not be any subsequent delays after that initial message.
Advanced Greylisting Settings:
Applies to MailEssentials
|Registry Value||Default Value||Setting|
|BlockPeriod||15 (mins)||Temporary Block Period|
|PassPeriod||4 (days)||Temporary Pass Period|
|AuthMaintPeriod||35 (days)||Authorized Maintenance Period|
|TempMaintInterval||2 (hours)||Temp Table Maintenance Interval|
|AuthMaintInterval||12 (hours)||Authorized Table Maintenance Interval|
|ExcludeOnlyWLSMTP||0||Flag which sets if only Whitelist SMTP addresses are used for exclusion list. Set to 1 to use only Whitelist SMTP addresses|
When flag is set to 1, message will be blocked if not all recipients are authorized. When flag is set to 0, message will be not be blocked if at least one recipient is authorized.