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

> urgh, that's bad. now fixed


> > - 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.