Subject: [yam] Resent-From and Mailing Lists

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 13 Apr 2010 13:06:03 +0100

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:

   Resent fields are strictly informational.  They MUST NOT be used in the normal
   processing of replies or other such automatic actions on messages.
...
      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.

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), although I know that for example Mailman does not use it but instead the Reply-To/From if it cannot identify the subscriber.  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.

To be clear, is there anything wrong with "Authenticating" against Resent-From, as one might "Authenticate" against From?  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?  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?

Cheers,
Sabahattin

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Apr 2010 14:28:25 +0200

Sabahattin Gucukoglu writes:
> 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?

I think what you have discovered is that Resent-* is falling out of use 
and that some software has stopped supporting it.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Apr 2010 17:16:19 -0700 (PDT)

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

Their reading is a bit deficient. See below.

>    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.

>       are only informational and MUST NOT be used in the normal

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

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 14 Apr 2010 19:53:26 +0100

Thanks Ned.  A very cogent response indeed.  I'll refer it to the mlmmj people, and if nothing else see about patching my own copy or, if there are enough warts, finding another MLM.

> claiming that RFC 5322 says they have to do things this way. IMO it says

Right, yes.  And this was the turning point, IMO.  The fact that those headers are explicitly called out as untouchable, reasonable given their use, was simply being misunderstood as license to kill.  Which is fine, but not for that reason.  Perhaps I can understand it, and perhaps not.

> supposed to go to the envelope from address and we have clear statements of
The quandary was always whether to reply or bounce, and as you say we've solved that one many times over already.  I'm convinced it works for mailing list auto messages too, but that is, as always, just my opinion.  At least one mailing list manager uses the envelope for everything, requests, authentication, everything.

> legitimate usages, and this is one such case.

That's fine.  And there are real concerns about impersonation associated with Resent-* fields.  So, for the record, I would like to formally state that I hereby authorise myself to resend messages of interest to members of my own mailing list, there to illicit possible replies, to the originator or to the list as desired, by its subscribers, and to permit others on that list to do likewise. :-)

Cheers,
Sabahattin