Re: [yam] Resent-From and Mailing Lists

Sabahattin Gucukoglu <> Wed, 14 April 2010 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06AB23A68B9 for <>; Wed, 14 Apr 2010 11:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.024
X-Spam-Level: ***
X-Spam-Status: No, score=3.024 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_40=-0.185, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wF0zk2nKCIF1 for <>; Wed, 14 Apr 2010 11:53:36 -0700 (PDT)
Received: from ( [IPv6:2002:adcb:c9c7::1]) by (Postfix) with ESMTP id B57513A686D for <>; Wed, 14 Apr 2010 11:53:35 -0700 (PDT)
Received: from ([::ffff:]:54063) by with [XMail 1.27 ESMTP Server] id <S3EC8> for <> from <>; Wed, 14 Apr 2010 19:53:29 +0100
Received: from [] ( []) (using SMTP over TLS) by Mintaka (tmda-ofmipd) with ESMTP; Wed, 14 Apr 2010 19:53:27 +0100
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary=Apple-Mail-1-906230098; protocol="application/pkcs7-signature"; micalg=sha1
Date: Wed, 14 Apr 2010 19:53:26 +0100
In-Reply-To: <>
References: <> <>
Message-Id: <>
X-Mailer: Apple Mail (2.1078)
X-Delivery-Agent: TMDA/1.1.12-kg2 (Pluto)
From: Sabahattin Gucukoglu <>
Subject: Re: [yam] Resent-From and Mailing Lists
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Sabahattin Gucukoglu <>
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Apr 2010 18:53:37 -0000

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.

On 14 Apr 2010, at 01:16, Ned Freed wrote:
> 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.

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.

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

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

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