Re: [yam] Resent-From and Mailing Lists

Ned Freed <ned.freed@mrochek.com> Wed, 14 April 2010 00:51 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11F628C1B5 for <yam@core3.amsl.com>; Tue, 13 Apr 2010 17:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.989
X-Spam-Level:
X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewguPdfgim-L for <yam@core3.amsl.com>; Tue, 13 Apr 2010 17:51:02 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id AADD628C16D for <yam@ietf.org>; Tue, 13 Apr 2010 17:51:02 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NLWUKJ1RCG00APVO@mauve.mrochek.com> for yam@ietf.org; Tue, 13 Apr 2010 17:50:48 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NLSX5QXE280000BI@mauve.mrochek.com>; Tue, 13 Apr 2010 17:50:44 -0700 (PDT)
Message-id: <01NLWUKGG6LQ0000BI@mauve.mrochek.com>
Date: Tue, 13 Apr 2010 17:16:19 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 13 Apr 2010 13:06:03 +0100" <278D6DA9-ED4A-4737-9168-C93B188EFFE0@sabahattin-gucukoglu.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <278D6DA9-ED4A-4737-9168-C93B188EFFE0@sabahattin-gucukoglu.com>
To: Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com>
Cc: yam@ietf.org
Subject: Re: [yam] Resent-From and Mailing Lists
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2010 00:51:03 -0000

> Hi all,

> I am puzzled.  I contacted the mlmmj (a mailing list manager) mailing list, with a query about mails being rejected on mlmmj-run mailing lists when resent.  The mailing list manager would reject mail, sending the rejection notice to the From: person, because the subscriber resending the message was in the subscriber list but the From: person was not, and because the From: person was the one being checked.  The effect is that the originator, not the subscriber, gets a notice and the mail goes nowhere, even though the Resent-From header would have authenticated the subscriber to the mailing list, allowing him to mail to the membership a message coming from the originator, just as Resent-* headers are supposed to.

> The maintainer quotes this passage from RFC 5322 as justification for this
> behaviour:

Their reading is a bit deficient. See below.

>    Resent fields are strictly informational.  They MUST NOT be used in the normal
>    processing of replies or other such automatic actions on messages.

The restriction against using resent- for replies is reasonable and in line
with the stated semantics of resent-*, which are roughly that the person doing
the resending is "in the background" and should not be dragged into any ongoing
conversation willy-nilly.

As for the more general restriction on "automatic" processing, it depends on
what you mean by "automatic". I'm not aware of this term having a formal
definition, but note the presence of the "such" before - this is clearly
talking about other sorts of automatic response processing, further forwarding
and so on.

What it clearly isn't doing is talking about all forms of message processing.
Such a restriction would be completely absurd - it would even prevent use of
the fields for logging and display purposes. If you take that view, you then
have to accept that there's no way for these fields to be used in both a
compliant and interoperable way, which then would more or less require the
removal of this capability before the specification moves to standard.

So where does mailing list procesing fit in all of this? The answer is it
doesn't. There's nothing here that prohibits examination of resent- information
for mailing list permission checks and nothing that condones it either.

>       Note: When replying to a resent message, replies behave just as
>       they would with any other message, using the original "From:",
>       "Reply-To:", "Message-ID:", and other fields.  The resent fields
>       are only informational and MUST NOT be used in the normal
>       processing of replies.

And this is clearly only talking about replies. Mailing lists messages
are not replies so this is totally irrelevant.

> So, it seems there is some connection with automatic action being
> unsupportable specifically because the Resent-* fields are given this
> prohibition, rather than the From:, even though neither is really correct
> because neither is suitable for automatic replies, while the check against the
> Resent-* fields clearly does not mean that a rejection message should be
> mailed there.  The envelope is clearly the right place to find the sender
> address for rejections (loops and all that),

I note in passing that use of envelope from for list permission checks is
also possible.

> although I know that for
> example Mailman does not use it but instead the Reply-To/From if it cannot
> identify the subscriber. 

Which, given the almost total lack of guidance in the various RFCs as to how
mailing list processing should be done, is a legitimate approach. As are any
number of other approaches. There is no right or wrong here, only users pissed
off to one degree or another ;-)

> In any event, what this means is that, assuming the usual automatic responses
> being mailed using Reply-To/From, any mail sent as a result of resending needs
> special treatment in certain circumstances, like this one, which appear to
> violate RFC 5322, .  The only way this makes sense is for Resent-From: to
> receive any automatic replies, and that is clearly wrong, while the
> originator is clearly also not required to be a member of a mailing list for
> Resent to be, at least semantically, supportable.

These are all questions of list policy, and the answers are not specified in ay
IETF document AFAIK.

> To be clear, is there anything wrong with "Authenticating" against
> Resent-From, as one might "Authenticate" against From?

Not that I know of. My reading of RFC 5322 certainly imposes no such
restrictions. But at the same time, nothing requires that list authentication
processes look at these fields.

In other words, the mistake the mlmmj folks are making isn't that they are
ignoring resent-* fields - which they are entirely free to do - but rather in
claiming that RFC 5322 says they have to do things this way. IMO it says
nothing of the sort.

> This mailing list manager at least does not support post acknowledgements, so
> there would be no need to reply if the subscriber could be verified.

> I understand absolutely the intent of the paragraph that states replies go to
> the originator, but what does this say for automatic responders more
> appropriate for the sender and not the originator?  Is this the vacation
> quandary all over again?

I'm not sure what you mean by "vacation quandary", but vacation responses are
supposed to go to the envelope from address and we have clear statements of
that in various RFCS.

  Or have I simply misused the resend function, that of
> allowing my mailing list participants to see a message as sent to me, often
> from another mailing list?

It doesn't sound like you've misused the function, but that doesn't mean your
usage complies with the policies of the lists you're posting to. Like it or
not, local policy is in many cases allowed to block various perfectly
legitimate usages, and this is one such case.

				Ned