Mark Martinec writes: > On Friday 11 April 2008 11:13:09 Jason Haar wrote: > > So are you saying as I know what all our relays are (ie > > whitelist_bounce_relays), I should pump that score up to 20, and > > effectively blacklist (we block at scores >10) any bounces (which should > > just happen to be 100% forged spam) sent from anyone in the world using > > our domains - which isn't from our relays? > > 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. > - 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? > - 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 > - message disposition notifications (MDN, RFC 3798); fixed already > - out of office replies (alright, no damage there); Unless the message contains the relays -- this is by design. ;) A good portion of my blowback was OOO noise. > 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. In general, bug reports on these, with samples, would be welcome. --j.
