| Rob> Now SPAM's getting through this "loop hole". Is there any way to | Rob> whitelist based upon Recipient to:, or am I just screwed? | | Can't you just define a "header" rule, such as | | header REALLY_ME To =~ [EMAIL PROTECTED]/ | describe REALLY_ME To: indicates it's for me | score REALLY_ME -5.0
The SMTP envelope address (sender and recipients) is quite a different thing than the RFC822 addresses inside the mail header. Especially with spam (and viruses) they frequently bear no relationship one to another. As far as mailer (MTA) is concerned, the addresses inside the header are completely irrelevant. Also some recipient addresses are not available inside the header - it is a requirement for a MTA that it removes 'Bcc:' addresses from the header! Similarly for 'undisclosed-recipients' - they are not available inside the header. When I integrated SA into amavisd-new, I had to provide my own whitelisting of envelope sender addresses, as there is currently no way to pass envelope addreses to SA, and there is no mechanism inside SA that would check the RFC821 addresses. Also the envelope addresses are 'clean', in contrast to the rfc822 header addresses, which need to be parsed to separate them from comment fields, and this parsing has to take into account 'old' and 'newstyle' comment fields and may be victimized by clobbered header. I would be very happy to move the envelope sender whitelisting off the amavisd-new and into SA, where it really belongs. Please consider this as a 'request for enhancement': - please provide a mechanism where an application can pass envelope addresses (SMTP originator and recipients) to SA, e.g. via the Mail::SpamAssassin::NoMailAudit->new call (or otherwise); - provide a whitelist/blacklist mechanism that can operate on the envelope addresses; - while at it, there may be an opportunity for MTA to pass the IP address of the originating SMTP host to a content filter - might be useful, as otherwise this information is (partly) lost - can be available in the 'Received:' headers, but there is no guarantee and no simple way to parse them. There is probably an extra benefit of having envelope addresses available to SA rules. Regards Mark -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! Mark Martinec (system manager) tel +386 1 4773-575 !! !! J. Stefan Institute, Jamova 39 fax +386 1 2519-385 !! !! SI-1000 Ljubljana, Slovenia [EMAIL PROTECTED] !! !!!!!!!!!!!!!!!!!!!!!!!!!! http://www.ijs.si/people/mark/ !!!! _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
