Re: Mailing list membership.

[willi uebelherr <[e-mail]>]

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