Mailing List Archive

Thus said "Joshua Megerman" on Fri, 21 Nov 2014 10:27:29 -0500:

> 1) Should I continue to use greylisting, or is it no longer a useful
> thing to do?

It is indeed still useful/relevant, however, it depends on your actual
spam volume and the source of the spam. If you are getting hammered with
a lot of anonymous spam coming from botnets, then greylisting is
extremely useful. This is something you alone can know by analyzing your
spam traffic and deciding if greylisting will help. I also find a
smallish ``greet delay'' to be effective.

> 2) If yes, is there a particular implementation that's considered
> "better" than others, and/or what are the pros/cons of specific
> implementations?

I prefer to leave greylisting out of qmail and just use OpenBSD's
spamd[1] for it. That way I keep qmail sources cleaner and let something
that was designed to handle a lot of spam deal with it.

[1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-5.6/man8/spamd.8?query=spamd&manpath=OpenBSD-5.6

Andy
--
TAI64 timestamp: 40000000546f830a

Op 21-11-14 om 16:27 schreef Joshua Megerman:
> I'm in the process of updating my qmail setup in preparation for a server
> migration, and I'm wondering if greylisting is something I should continue
> to include, and if so which implementation is best. My questions boil
> down to these:
>
> 1) Should I continue to use greylisting, or is it no longer a useful thing
> to do?

Yes it is!
Our stats:
OK-mails: 15.422.053
Whitelisted: 6.323.428
Local: 6540796

NoProcessing: 1.098.990
NoFiltering: 1.043.813

Greylisting: 25.747.331
Penaly Trap: 8.621.041
Invalid HELO: 7.620.332
Message Scoring: 1.918.908
RBL-failures: 682.242

All others (including DKIM SPF URI-bl, etc.) less then 100.000



> 2) If yes, is there a particular implementation that's considered "better"
> than others, and/or what are the pros/cons of specific implementations?
> I've found several, but I'd rather have people point me at their preferred
> implementations for a clean assessment.

We use assp (sourceforge), for about 10 years, but it has become to
complicated. Only the main-configfile has now more then 1.000 variables.

We are now testing mailcleaner.

Both these spam-programs run in front of qmail.



> 3) If I do implement greylisting, what's the preferred tuple? Strict IP
> address? Class C network? Something else?

We use Strict IP


> 4) Similarly, what's the preferred deferral time? 5 minutes? Or
> something else?

We use 3 minutes.

> Thanks in advance for the responses!
> Josh
>
> Joshua Megerman
> SJGames MIB #5273 - OGRE AI Testing Division
> You can't win; You can't break even; You can't even quit the game.
> - Layman's translation of the Laws of Thermodynamics
> josh@honorablemenschen.com
>

Josh,


On 2014-11-22 02:27, Joshua Megerman wrote:
> I'm in the process of updating my qmail setup in preparation for a
> server
> migration, and I'm wondering if greylisting is something I should
> continue
> to include, and if so which implementation is best. My questions boil
> down to these:
>
> 1) Should I continue to use greylisting, or is it no longer a useful
> thing
> to do?
> 2) If yes, is there a particular implementation that's considered
> "better"
> than others, and/or what are the pros/cons of specific implementations?
> I've found several, but I'd rather have people point me at their
> preferred
> implementations for a clean assessment.
> 3) If I do implement greylisting, what's the preferred tuple? Strict
> IP
> address? Class C network? Something else?
> 4) Similarly, what's the preferred deferral time? 5 minutes? Or
> something else?
>
> Thanks in advance for the responses!


I still use GreyLite with Qmail although it hasn't been supported for
some time . .

P.

--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

On Saturday 22 Nov 2014 19:25:29 Philip Rhoades wrote:
> On 2014-11-22 02:27, Joshua Megerman wrote:
> > 1) Should I continue to use greylisting, or is it no longer a useful
> > thing to do?

Yes I think so: It's very lightweight on server resources (when done right)
and does still catch a useful amount of email attempts from presumed botnets.

> > 2) If yes, is there a particular implementation that's considered
> > "better" than others, and/or what are the pros/cons of specific
> > implementations?
> > I've found several, but I'd rather have people point me at their
> > preferred implementations for a clean assessment.

I'm biased: Here's mine/John Levine's,

http://free.acrconsulting.co.uk/email/grey.html

> > 3) If I do implement greylisting, what's the preferred tuple? Strict
> > IP address? Class C network? Something else?

Strict IP + envelope sender(s) + envelope recipient addresses: These are all
available prior to the SMTP DATA command so greylisting is then particularly
frugal on bandwidth.

When I did look at other implementations years ago I found that some
implementations vary in their 'triple' (tuple), so when evaluating greylisting
implementations it's well worth looking to see just what they're recording and
to think about whether the author understands what they're doing (I seem to
remember one implementation that recorded the 'From:' header rather than the
envelope FROM address - which will waste bandwidth). Some implementations are
also called in such a way that the whole message is received prior to the
greylisting test being applied - again this results in unnecessary bandwidth
use.

I did toy with varying the IP address to its class C network instead
(straightforward to adapt the above implementation for this if that's what you
choose to do), but in fact it all seems to work fine with strict IP addresses
assuming that you do add the occasional custom exception to a greylisting
white list. I provide a possible whitelist via the above web page.

It's worth recording stats on your greylisting performance so that you can get
an ongoing sense of whether it's effective for your specific use-case; I find
munin graphs helpful to judge this, along with graphing other anti-spam
measures.

> > 4) Similarly, what's the preferred deferral time? 5 minutes? Or
> > something else?

Legitimate retries often happen pretty quickly - just 1 minute may be just fine
for most purposes and help minimise any inconvenience to recipients waiting
for incoming emails.

> > Thanks in advance for the responses!
>
> I still use GreyLite with Qmail although it hasn't been supported for
> some time . .

There is a larger question regarding all IPv4-based anti-spam measures like
greylisting and RBLs, and that is email being sent from IPv6-addressed
servers. Email servers for the moment remain mostly IPv4-based, but I expect
that will change.

Best regards,

Andrew.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/email/qmail.html
====================================================================

Geachte heer, mevrouw,



Hartelijk dank voor uw e-mail. Binnen 2 werkdagen ontvangt u van ons een reactie op uw vraag of klacht. Wist u dat u bij de ING ook veel zaken online kunt regelen? Bijvoorbeeld het beheren van uw geldzaken, het aanvragen van nieuwe producten, tot aan het wijzigen van uw gegevens. Meer weten? Klik hier: http://www.ing.nl/particulier/internetbankieren/index.aspx"]www.ing.nl/particulier/internetbankieren/index.aspx



Dit is een automatische ontvangstbevestiging.



Met vriendelijke groet,



ING Bank N.V.



-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

Andrew,


On 2014-11-23 00:37, Andrew Richards wrote:
> On Saturday 22 Nov 2014 19:25:29 Philip Rhoades wrote:
>> On 2014-11-22 02:27, Joshua Megerman wrote:
>> > 1) Should I continue to use greylisting, or is it no longer a useful
>> > thing to do?
>
> Yes I think so: It's very lightweight on server resources (when done
> right)
> and does still catch a useful amount of email attempts from presumed
> botnets.
>
>> > 2) If yes, is there a particular implementation that's considered
>> > "better" than others, and/or what are the pros/cons of specific
>> > implementations?
>> > I've found several, but I'd rather have people point me at their
>> > preferred implementations for a clean assessment.
>
> I'm biased: Here's mine/John Levine's,
>
> http://free.acrconsulting.co.uk/email/grey.html
>
>> > 3) If I do implement greylisting, what's the preferred tuple? Strict
>> > IP address? Class C network? Something else?
>
> Strict IP + envelope sender(s) + envelope recipient addresses: These
> are all
> available prior to the SMTP DATA command so greylisting is then
> particularly
> frugal on bandwidth.
>
> When I did look at other implementations years ago I found that some
> implementations vary in their 'triple' (tuple), so when evaluating
> greylisting
> implementations it's well worth looking to see just what they're
> recording and
> to think about whether the author understands what they're doing (I
> seem to
> remember one implementation that recorded the 'From:' header rather
> than the
> envelope FROM address - which will waste bandwidth). Some
> implementations are
> also called in such a way that the whole message is received prior to
> the
> greylisting test being applied - again this results in unnecessary
> bandwidth
> use.
>
> I did toy with varying the IP address to its class C network instead
> (straightforward to adapt the above implementation for this if that's
> what you
> choose to do), but in fact it all seems to work fine with strict IP
> addresses
> assuming that you do add the occasional custom exception to a
> greylisting
> white list. I provide a possible whitelist via the above web page.
>
> It's worth recording stats on your greylisting performance so that you
> can get
> an ongoing sense of whether it's effective for your specific use-case;
> I find
> munin graphs helpful to judge this, along with graphing other anti-spam
> measures.
>
>> > 4) Similarly, what's the preferred deferral time? 5 minutes? Or
>> > something else?
>
> Legitimate retries often happen pretty quickly - just 1 minute may be
> just fine
> for most purposes and help minimise any inconvenience to recipients
> waiting
> for incoming emails.
>
>> > Thanks in advance for the responses!
>>
>> I still use GreyLite with Qmail although it hasn't been supported for
>> some time . .
>
> There is a larger question regarding all IPv4-based anti-spam measures
> like
> greylisting and RBLs, and that is email being sent from IPv6-addressed
> servers. Email servers for the moment remain mostly IPv4-based, but I
> expect
> that will change.


Good point - this will need monitoring I guess . .

Regards,

Phil.

--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

Hi Josh,

considering anti-spam methods, we/you have the following choices:

Methods + cons:

a) RBLs (like Spamhaus): This a traditional way. Unless you fetch the RBL
from the provider and use it locally, you will automatically leak your SMTP
communication to Spamhaus (or any other). Further, your SMTP communication
is determined by the 'willingness' of the RBL provider.

For instance, the IP of my (Germany hosted) root server is part of russian
based IP block. Too bad. Regulary I'm blocked by Hotmail (Microsoft)
because they to it wrong.

Further, RBLs are not supposed to work (well) with IPv6; though my
ucspi-tcp6 includes IPv6 RBL support for rblsmtpd.

b) Greylisting: As local based method you control the behaviour.
The bad thing about this is: (i) you need to maintain a stateful database
(+ clean ups etc). (ii) In case a legitimate sender is refrained and is
incapable to respond in time, the mail is delayed.
Actually, it is not your system determing the delay of mails but rather the
scheduler of the remote system - you don't know.

a) and b) are stateful methods.

c) Greetdelay: Is part of some qmail patches and my ucspi-tcp6: It binds
the sending MTA for a certain period YOU chose (on behalf of the IP
address). Of course, unlike Greylisting it binds in addition the resources
of your MTA (sockets).

It works stateless. You don't need to maintain a connection database. But
some tweaking is possible (for instance: I don't greetdelay mails from this
list server -- and other broken MTAs).


Now the pros:

- RBLs are working fine still (if you use the appropriate ones).
- Greylisting is working great as well regarding bots.
- Greetdelay is also a good anti-spam method against bots.


Neither Greylisting nor Greetdelay impact real MTAs significantly -- unlike
RBLs.

I dont't now if it makes sense to combine b) and c); however you can.

As with all methods, you have to determine the effectiveness. Within the
set of my solutions for qmail, you can measure the number of refrained SMTP
connections in case a) and c).

For instance, I have set up a MRTG for my qmail system (which idles most
the time):

<https://www.fehcom.net/qmail.html>

The difference between 'connections' and 'sessions' shows the efficiency of
RBLs+Greetdelay -- have a look a the peaks; the spam storms from bots.



Best regards.
--eh.









--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE