Re: Low Scores on Bounce Backs
On Friday 11 April 2008 15:05:59 Justin Mason wrote:[color=blue]
> Mark Martinec writes:[color=green]
> > 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;[/color]
> samples of these FPs would be welcome.[/color]
Ok, opening the:
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;[/color]
> yeah, that's true. have you seen this happening?[/color]
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@example.com>;[/color]
> urgh, that's bad. now fixed[/color]
> > - message disposition notifications (MDN, RFC 3798);[/color]
> fixed already[/color]
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.[/color]
> it doesn't? feel free to open a bug.[/color]
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.