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
- [yam] Resent-From and Mailing Lists Sabahattin Gucukoglu
- Re: [yam] Resent-From and Mailing Lists Arnt Gulbrandsen
- Re: [yam] Resent-From and Mailing Lists Ned Freed
- Re: [yam] Resent-From and Mailing Lists Sabahattin Gucukoglu