On 01/30/2018 11:38 PM, Peter Münster wrote:
On Tue, Jan 30 2018, Mark Sapiro wrote:
The underlying issue is the orange.fr domain is sending DSNs without a Message-ID: header.
Yes. Is a Message-ID header required in a DSN by any RFC?
It's not a MUST, just a SHOULD, but RFC 5322, sec 3.6.4 says
Though listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field.
If you used VERP (i.e. set verp_delivery_interval = 1 in the [mta] section of your config), this log message
I have verp_delivery_interval = 10 ...
Which says only every 10th message will be VERPed. You want verp_delivery_interval = 1 to VERP every message.
would contain email@example.com and you could identify the bouncing address (firstname.lastname@example.org in this case) that way.
Yes, that's my intention, but first of all, mailman must receive the DSN.
The message does appear in the mail log, but until the issues below are fixed, even if Mailman receives it, you won't see it.
Beyond that, there are still other issues, the biggest of which is currently, Mailman is not processing bounces other than storing them in the database. See https://gitlab.com/mailman/mailman/issues/343.
Shouldn't the DSNs be forwarded to the owner of the list?
They should be processed by Mailman and scored as bounces for the recipient if recognized and forwarded if not (depending on settings), but they currently are only stored.
if a recipient MTA can't create a DSN that has a Message-ID:, would you trust what else it does?
I don't know. The question for me is: does the remote MTA needs a fix (i.e. the Message-ID is required by some RFC), or mailman (i.e. a DSN without Message-ID should be acceptable)?
I have filed https://gitlab.com/mailman/mailman/issues/448 for this.
-- Mark Sapiro email@example.com The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan