Re: Mailing list membership.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]