Thus spake Julian Mehnle on Tue, Apr 27, 2004 at 06:39:46PM CDT > Lindsay Haisley [EMAIL PROTECTED] wrote: > > What's the current status of SPF and Courier? I note that SPF can be > > implemented as a 3rd party filter via a perl object library, but does > > this handle issues such as sender address rewriting (I have _lots_ of > > customer mail redirections on my mail server)? > > No, Courier::Filter::Module::SPF does not do sender address rewriting (it > technically cannot do this in an elegant way).
Having worked with courier filters a bit, I kind of figured as much. > Although the SPF concept as a whole cannot work without sender address > rewriting (using SRS or some custom method), SPF checking and sender > address rewriting are distinct concepts. Theoretically, for your server > to do SPF checking when receiving messages, you don't need to rewrite > sender addresses when forwarding, i.e. sending, messages. Only when a > server you forward messages to performs SPF checking is sender address > rewriting required. I'm just learning about SPF (thanks to recent LJ articles!), and it looks as if down the road we really need to see the adoption of SPF or something similar "as a whole" if the spam/virus problem is going to be addressed effectively. There are truly holes in SMTP that require fixing. > For an elegant solution, sender address rewriting would need to be > integrated directly into Courier. I had pretty much figured that this would be the case, which is the point of my post. I'm already studying your Courier::Filter perl object library to see what it can do. I wrote my own perl virus filter for courier some time back, which is quite effective, but the OOP framework for your object library is much more elegant than anything I did :-) > As far as I know Sam doesn't like the SPF concept and thus, SPF or sender > address rewriting isn't one of his priorities. *I* do like SPF, so maybe > I will at some point create a proper patch, but it is highly unlikely that > this will happen within the next 6 months. Pity. Sam has done a tremendous amount of _really_ good work in fighting spam over the years, starting with his elegant qmail anti-spam patches from the late 90s with which I worked extensively. I've been running courier on my professional server for a couple of years now, and am heavily invested in it in terms of system configuration scripts, database design, etc. The Internet email system is truly in crisis right now (I speak as a mail administrator for a small online presence business and a consultant to a regional ISP) and anyone who provides leadership and guidance for a MTA package with as much industry penetration and reputation for innovation as courier is going to _have_ to address the issue. I hope it's soon. I'd hate to see courier supported by a collection of patches, since it's under active development. Qmail, for all it's quality, is supported going forward in this fashion since Dan Bernstein has essentially abandoned it. While the diff->patch system of updating source code works will for a single patch, it has absolutely _no_ scalability!! Publishing a patch on a package in active development has the added disadvantage that any patch is a shot at a moving target. Someone with sufficiently robust reputation needs to convince Sam that while SPF may not be the most elegant solution available, optional support for it in courier would be a distinct advantage. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | | ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
