This is a discussion on Re: Low Scores on Bounce Backs - SpamAssassin ; 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 ...
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);
> - 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.