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" ;

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.