Dear Theodore, many thanks for your explanation to the RFC 2821 (SMTP).
The answer from Khaled i have included, because it goes to me as a
private message.
Maybe, based on my bad english, i feel some confusion with the terms.
1) Khaled, like i and you, is member of the IETF discussion list. This
means, he receive all emails that are distributed over the list.
2) Khaled, like i and you, use the maillist server mailman from IETF
discussion list to distribute his messages to all members in the list.
3) The IETF discussion list don't follow the DMARC processing. This
means, it act only outside.
4) Khaled, like i and you, use a mail box server system as the
interconnection point to the list. Khaled use hotmail, you use mit.edu,
i use riseup.net.
This means, the actors are the mailbox servers with the mailman maillist
server IETF discuss in both direction.
I understand and agree absolutly, that the maillist server never change
the From-line in the header. He create the Return-Path-line and/or
Error-To-line for error response from the receiver mailbox server
system. The bounce-information.
The mailman maillist server use bounce-counters for every member and
some limits for this bounce-counter. If the limit exceeds, and the
admin-group do nothing, then the maillist server mailman disable the
delivery. It is not an unsubscription.
The admin-group have to follow the incremental increase of the
bounce-counters to understand, what is the background. Maybe, the
mailbox is full, or don't exist or is the result of this stupid DMARC
processing.
The DMARC processing is defined in the DNS info. But we can ignore it,
or not? The admin-group can inform the member to change her mailbox
server to "avoid more errors" like Khaled wrote. The IETF discussion
admin-group can only inform about the error sources. The members have to
change her mailbox servers, or not?
Based on that process, we can clean all this nonsense in our IETF lists
environment and work strong based on the RFC 2821, like mailman do it.
What do you think about?
many greetings, willi
On 01/03/2017 07:50, Khaled Omar wrote:
> Hi Willi,
>
>> Mailman never change the "From"-header. Therefore, the From-Header
always points to the author of the email. What you think, is that the
correct, compatible way? I think, yes.
>
> Such case is out of our hands, other e-mail service providers are
welcome to be used just if this will add a value and avoid more errors.
>
> Best Regards,
> Khaled
On 01/03/2017 01:49, Theodore Ts'o wrote:
On Tue, Feb 28, 2017 at 05:29:24PM -0300, willi uebelherr wrote:
related to the problem, what Khaled explained, what is your proposal?
What are your "compatible with internet mailing lists" mail systems?
RFC 2821, Simple Mail Transfer Protocol, section 3.10.2
"To expand a list, the recipient mailer replaces the
pseudo-mailbox address in the envelope with all of the expanded
addresses. The return address in the envelope is changed so that all
error messages generated by the final deliveries will be returned to
a list administrator, not to the message originator, who generally
has no control over the contents of the list and will typically find
error messages annoying."
This is the SMTP Envelope From field. The FROM field is not changed,
but the SMTP return address is changed, so that bounces go to the
mailing list administrator as opposed to the person who sends mail to
the mailing list.
Unfortunately, if you are using a system whose domain requests that
all recipients enforce DMARC alignment, this specifically instructs
recipients to bounce mail if the SMTP Envelope return address doesn't
match the FROM field in the header. This means that they won't see
mailing list mail as defined by the IETF Standards Track RFC 2821,
which specifically says that is acceptable (and in fact a good thing)
to change the SMTP envelope return address so that bounces (caused by
people changing where they work, etc.) go to an administrator who can
deal with them. But if the mailing list administrators gets too may
bounces, and it's because the sending domain is requesting that mail
be bounced, the only thing they can do is to unsubscribe the sender or
the recipient.
Hence mailing list systems that enforce DMARC, or request DMARC
processing, are fundamentally incompatible with mailing lists as
defined by section 3.10.2 of RFC 2821.
If you want to participate in such mailing list, one of the best ways
is to change to a mailing list system that doesn't do DMARC.
Best regards,
-Ted