[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Steve Crook wrote: | | One other thing that would sway my choice at the moment is support for | Greylisting and delegation of policy decisions to an external service. | For those that have no spam problems, this is unlikely to be an issue, | whist for those who do have to process large volumes of junk, it's | heaven sent.
I think Exim now has greylisting, but it is hard to keep abreast of the different mode and methods available to fight spam across all the MTAs. And again it is not just do they do it, but do they do it well, and is it easy to configure.
Certainly Postfix has comprehensive, but (for Postfix) slightly arcane syntax, facilities for handing email off to external filters (which it can now do before or after queuing to disk -- which matters because it affects whether you reject email at SMTP transaction time (which may mean no bounce - i.e. sending MTA creates bounce) or if the receiving MTA creates bounce). But then I can reject all Windows executables in Postfix with a one line regular expression, so why trouble inserting a virus filter. Similarly the "arcane" syntax tends to be the same for each module, so you can "cut and paste" the configuration changes you need most of the time.
I think Qmail does worse than the others here, as this is usually some sort of patch.
Greylisting can be done by third party daemon that sits in front of the MTA, like greylistd(?), so can be done by any MTA. Greylisting of course is specifically open to attack by spambots that use an appropriate algorithmn, and I've heard of false positives penalising overly keen mail servers. So whilst it probably works well at reducing spam I'm still a bit cautious.
I'm in two minds as to which is the best approach to add-on features like these. Part of me thinks it should be built into the MTA to provide the most integrated response, part of me believes it is smarter to move these into third party modules, whether before, after, or hooked into the MTA.
But then I'm running SMTP AUTH via a daemon, which I think is a smart solution even if the specific daemon has issues, compared to integrating it into the MTA (almost all MTAs provide SMTP AUTH as standard, but they may not as readily support PAM or other authentication methods).
I also think SMTP over SSL is smarter than putting the encryption into the email conversation (for submission) whatever the standards say. SMTP over SSL can be done through stunnel as a daemon, allowing a plain text alternative for debugging, although it does of course require a client configuration change to use the SMTP over SSL port. Of course to do it between MTAs requires the encryption as part of the protocol, but that is a different problem.
Unfortunately as the SMTP protocol gets more sophisticated our chances of getting away with layering technologies via modules will diminish I fear, and we'll be left with huge bloats MTAs that can't successfully send email to each other, and which we can't debug because it is all encrypted or hashed :( -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFBFKdFGFXfHI9FVgYRAtgFAKDLvt+3zrRckt8yRgexDVZui7bRxgCdETC4 2dP9NfJpdDY11Zm2hbr0a0M= =iOdk -----END PGP SIGNATURE-----
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.