Greylisting in Kerio Connect


2012/10/03

Greylisting is terribly misunderstood and Kerio's implementation of it is even more so. Learn why it is nothing to be feared.


Kerio Connect will be adding greylisting in the 8.0 release (most likely coming late 2012). Beta versions of this have been available for some time now, and have caused a good deal of confusion and misunderstanding in the Kerio beta forums.

The basic idea of greylisting is that the first attempt to send email to your mail server is rejected with a polite "Please try again later" code. Any legitimate email server will try again after a short delay and will be accepted; a spammer may not bother to try again.

Some things NOT to be concerned about:

If greylisting is turned on and Connect cannot contact the Kerio greylisting service hosted at Kerio, all incoming mail is delivered immediately, so there is no danger here.

There are no privacy issues. Kerio's greylisting server is not sent the body of the email. Only the sender envelope email address, the recipient envelope email address and the IP address of the host delivering the message are sent and they are sent over an encrypted connection. Further, although this is not so in the beta phase, when implemented only MD5 sums will be sent, not the actual text data of those headers. Finally, even that data will be periodically deleted.

If the greylisting is disabled, no data is sent to Kerio Technologies.

So what are people worried about?

Delays, of course. Let's see what happens when somebody sends me email on my grey-list enabled server:

[03/Oct/2012 17:06:45][3431] {greylist} Greylisting: testing mail
from <[email protected]> to <[email protected]> (and 0
other recipients) sent by 69.25.202.100.
[03/Oct/2012 17:06:45][3431] {greylist} Greylisting: allocated
connection object in 0 ms.
[03/Oct/2012 17:06:45][3431] {greylist}
Greylisting: Kerio Connect sent "GREYL 69.25.202.100
[email protected],[email protected]" over TLS.
[03/Oct/2012 17:06:45][3431] {greylist} Greylisting: service
responded "210 Delay" over TLS.
[03/Oct/2012 17:06:45][3431] {greylist} Greylisting is delaying mail,
query finished in 143 ms with result "DELAY".
[03/Oct/2012 17:06:45][3431] {greylist} Greylisting rejected mail
after DATA: 450 4.7.1 Please try again later

[03/Oct/2012 17:08:34][1864] {greylist} Greylisting: testing
mail from <[email protected]> to <[email protected]>
(and 0 other recipients) sent by 96.126.98.231.
[03/Oct/2012 17:08:34][1864] {greylist} Greylisting: allocated
connection object in 0 ms.
[03/Oct/2012 17:08:34][1864] {greylist}
Greylisting: Kerio Connect sent "GREYL 96.126.98.231
[email protected],[email protected]" over TLS.
[03/Oct/2012 17:08:34][1864] {greylist} Greylisting: service
responded "211 Pass" over TLS.
[03/Oct/2012 17:08:34][1864] {greylist} Greylisting is
accepting mail, query finished in 140 ms with result "PASS".
 

Note that there are two emails there. The first is politely rejected, the second is immediately accepted. Why was it accepted? Because Kerio's greylisting service has already learned that Gmail is an acceptable sender. Gmail will presumably eventually be deleted and it will have to suffer one rejection by somebody before it will be allowed to pass again, but for now, it gets a pass.

NOTE THIS CAREFULLY: It's not just Gmail to me that gets a pass from the greylisting server. it's Gmail to ANY Kerio greylisting using server. This is an important advantage to a common server: if the sender has behaved properly at MY server, they'll be automatically accepted at YOUR server - there will be no delay.

That bluestatedigital.com is not a spammer, so they will try again. Watch what happens:

[03/Oct/2012 17:14:35] Recv: Queue-ID: 506c565b-0000002e,
Service: SMTP, From: <[email protected]>, To:
<[email protected]>, Size: 5525, Sender-Host: 69.25.202.100,
Sender-Host-Name: mta-sample1.bluestatedigital.com,
Subject: RE: Go Get 'Em Barack!, Msg-Id:
<[email protected]>
[03/Oct/2012 17:14:42] Sent: Queue-ID: 506c565b-0000002e,
Recipient: <[email protected]>, Result: delivered, Status: 2.0.0
, Remote-Host: 127.0.0.1, Remote-Host-Name: localhost, Msg-Id:
<[email protected]>
 

Just eight minutes later, they tried again and this time were passed because the Kerio greylisting service has seen them before. If they sent another message today or next week, there would be no delay at all.

I hope you can see that delays will be rare and short - except in the case of real spammers!

Will spammers learn to bypass this?

Some may. After all, all they have to do is try again. Many will not: they are high volume operations and will simply assume the server no longer exists rather than trying again. However, if greylisting becomes popular, spammers may find it worth their while. The important thing to understand is that greylisting is just one weapon in your arsenal of spam fighting methods.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Greylisting in Kerio Connect




Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





We made the buttons on the screen look so good you'll want to lick them. (Steve Jobs)

If you tell the truth you don't have to remember anything. (Mark Twain)








This post tagged: