On Friday 11 April 2008 15:05:59 Justin Mason wrote: > Mark Martinec writes: > > It would also block some messages which you may or may not want to block, > > such as: > > - some automatic notifications such as calendar/meeting reminders, > > notifications from ticketing/PR systems (OTRS), status reports, > > job completion reports and similar automatic notifications; > > samples of these FPs would be welcome.
Ok, opening the: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5882 providing a couple of samples. > > - messages with NOTIFY=NEVER in DSN options, which some upstream MTA > > converted to a null return path when the next MTA in chain does not > > support DSN; > > yeah, that's true. have you seen this happening? Not frequently enough to warrant worrying about it. > > - mail from senders which happen to have a word 'postmaster' in the > > author's name: From: "ICSOFT Secretariat" <[EMAIL PROTECTED]>; > > urgh, that's bad. now fixed Thanks! > > - message disposition notifications (MDN, RFC 3798); > > fixed already I'm not sure if attachment #5 to the above bug 5882 is one of them. I see log entries (subject, from, message-id) which lets me believe there are more of these, but it is hard for me to get the actual received samples from our users. > > Also, the parsing of Received by VBounce.pm is rather simpleminded. > > Typically it only sees a HELO name in the Received 'from' subfield, > > as it does not examine continuation lines of Received header fields, > > and is distracted by parenthesis in a tcp-info field. > > it doesn't? feel free to open a bug. It doesn't. Still, the HELO from a well behaved MTA usually does contain the fqdn of the MTA host, so the simpleminded regexp match on the first line is lucky more often than not. To do a proper parsing of Received subfields would involve substantial code. I'll let it pass for the time being, unless someone feels otherwise. Mark
