Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Dave Korn]

[ This is completely off-topic, so moved to the proper list. ]
Paul McFerrin wrote:
> Dave:
> 
> I examined your email headers and discovered that in your postings to 
> cygwin ARGH DO NOT POST EMAIL ADDRESSES TO THE LIST cygwin.com, you are
> setting "Return-Path: <dave.korn.cygwin PCYMTNQREAIYR googlemail.com>" in
> your email header so naturally everyone who is "replying" to sender will be
> sending YOU their reply, not cygwin ARGH cygwin.com.  This could explain why you
> are getting so much direct replies.

  That's not actually what's happening.  Here is the raw text of my most
recent list posting at sourceware:

http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49ADFA41.4050308%40gmail.com

  As you can see there is no such header.  Here are a few others; likewise.

http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49ADE7FF.80005%40gmail.com
http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49ADE7DC.6030205%40gmail.com
http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49ADBA0D.6040405%40gmail.com
http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49AD9861.7050601%40gmail.com

  Notice how the Return-Path in all of these posts is a munged version of the
list subscriber name, as should be the case in all posts sent out by the
sourceware mailing lists; that way, if mail bounces, it is returned to the
list daemon, which can find out which list subscriber is bouncing and stop
sending messages if they carry on bouncing them for too long.

  Note also how all those paths have a Mail-Followup-To header pointing at the
list.  Any mailer that does not respect that when you hit Reply is broken and
does not comply with internet standards.  The Return-Path is for automated
error messages *only*, not replies of any sort.

  Also, here is a screenshot of my email settings, where I do not have any
Reply-To header set:

http://img530.imageshack.us/img530/3118/mysettings.png

  You'll just have to take my word for it that I haven't changed them since
you suggested this, although the historical record of my posts in the archive
backs me up on this.  Here also are the headers of one of the posts in my
local sent items folder (modulo obvious anti-spam munging)

From - Tue Mar 03 23:15:26 2009
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:

Message-ID: <49ADBA0D.6040405@gmail.com>
Date: Tue, 03 Mar 2009 23:15:25 +0000
From: Dave Korn <dave SPOT korn SPOT cygwin SPLAT gmail SPOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin SPLAT cygwin SPOT com
Subject: Re: concurrent use of cygwin1.dll for 1.5 & 1.7 ??
References: <49ADA916.40700@columbus.rr.com>
In-Reply-To: <49ADA916.40700@columbus.rr.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

corresponding to the message mentioned previously at

http://sourceware.org/cgi-bin/get-raw-msg?listname=cygwin&date=2009-03&msgid=49ADBA0D.6040405%40gmail.com

  Note that it also has no return-path header.

  Also, to see how the email headers look when they're received downstream
from sourceware, I went to gmane to look for the same post there.

Path: news.gmane.org!not-for-mail
From: Dave Korn <dave SPOT korn SPOT cygwin SPLAT googlemail SPOT com>
Newsgroups: gmane.os.cygwin
Subject: Re: concurrent use of cygwin1.dll for 1.5 & 1.7 ??
Date: Tue, 03 Mar 2009 23:15:25 +0000
Lines: 17
Approved: news SPLAT gmane SPOT org
Message-ID: <49ADBA0D.6040405@gmail.com>
References: <49ADA916.40700@columbus.rr.com>
NNTP-Posting-Host: lo.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: ger.gmane.org 1236121596 6607 80.91.229.12 (3 Mar 2009 23:06:36 GMT)
X-Complaints-To: usenet SPLAT ger SPOT gmane SPOT org
NNTP-Posting-Date: Tue, 3 Mar 2009 23:06:36 +0000 (UTC)
To: cygwin SPLAT cygwin SPOT com
Original-X-From: cygwin-return-148486-goc-cygwin=m SPOT gmane SPOT org SPLAT
cygwin SPOT com Wed Mar 04 00:07:52 2009
Return-path: <cygwin-return-148486-goc-cygwin=m SPOT gmane SPOT org SPLAT
cygwin SPOT com>
Envelope-to: goc-cygwin SPLAT gmane SPOT org
Original-Received: from sourceware.org ([209.132.176.174])
	by lo.gmane.org with smtp (Exim 4.50)
	id 1LediC-0006oG-50
	for goc-cygwin SPLAT gmane SPOT org; Wed, 04 Mar 2009 00:07:44 +0100
Original-Received: (qmail 15139 invoked by alias); 3 Mar 2009 23:06:14 -0000
Original-Received: (qmail 15131 invoked by uid 22791); 3 Mar 2009 23:06:13 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Original-Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com)
(74.125.78.145)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03
Mar 2009 23:06:07 +0000
Original-Received: by ey-out-1920.google.com with SMTP id 26so497818eyw.20
     for <cygwin SPLAT cygwin SPOT com>; Tue, 03 Mar 2009 15:06:04 -0800 (PST)
Original-Received: by 10.210.117.1 with SMTP id
p1mr1670744ebc.9.1236121564306;         Tue, 03 Mar 2009 15:06:04 -0800 (PST)
Original-Received: from ?82.6.108.62?
(cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62])         by
mx.google.com with ESMTPS id k9sm10716748nfh.62.2009.03.03.15.06.03
(version=SSLv3 cipher=RC4-MD5);         Tue, 03 Mar 2009 15:06:04 -0800 (PST)
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
In-Reply-To: <49ADA916.40700@columbus.rr.com>
Mailing-List: contact cygwin-help SPLAT cygwin SPOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-goc-cygwin=m SPOT gmane SPOT org
SPLAT cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe SPLAT cygwin SPOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin SPLAT cygwin SPOT com>
List-Help: <mailto:cygwin-help SPLAT cygwin SPOT com>,
<http://sourceware.org/ml/#faqs>
Original-Sender: cygwin-owner SPLAT cygwin SPOT com
Mail-Followup-To: cygwin SPLAT cygwin SPOT com
Delivered-To: mailing list cygwin SPLAT cygwin SPOT com
Xref: news.gmane.org gmane.os.cygwin:104617
Archived-At: <http://permalink.gmane.org/gmane.os.cygwin/104617>

  As before, you can see that the return path is the proper bounce address for
auto-unsubscribing, and the Mail-Followup-To points to the list.




  So, I trust there is no doubt that at least one of us knows how to drive a
mailer.  However, I'm willing to take your word for it that you have
experienced some kind of confusion or misunderstanding at your end through no
malicious intent of your own.  It strikes me that you could be the innocent
victim of a buggy mail server at your ISP.  (Come to think of it, this is RR
we're talking about; it would be a surprise if you /weren't/ suffering from
lousy servers at your ISP....)  You were unlucky to be the 'n'th person in a
row to mail me and be there at just the point when I lost patience, but I
don't suppose they all have faulty ISP mailservers.

  The text in RFC5321 that defines the Return-Path header is as follows:

When the delivery SMTP server makes the "final delivery" of a
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.  Here, final delivery means the message
   has left the SMTP environment.  Normally, this would mean it had been
   delivered to the destination user or an associated mail drop, but in
   some cases it may be further processed and transmitted by another
   mail system.

(http://tools.ietf.org/html/rfc5321)

  What this implies is that the bogus Return-Path header must have been
generated at your ISP mailserver, and I can guess what it's doing wrong: it's
using the address in the From: line in the email (rfc822) headers, rather than
the address in the "MAIL FROM" command when it receives the email from
sourceware.org, which sourceware.org will be presenting as the munged version
containing the subscribed user's address.

  So, I see that you are the victim of an unfortunate accident, although I
maintain that sending me the same request twice five minutes apart was a bit
pushy.  I've unblocked your address; please remember that, through no fault of
your own, you'll have to take more care in future.

    cheers,
      DaveK

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Owen Rees]

--On Wednesday, March 04, 2009 12:07:31 +0000 Dave Korn wrote:

>   Note also how all those paths have a Mail-Followup-To header pointing
> at the list.  Any mailer that does not respect that when you hit Reply is
> broken and does not comply with internet standards.  The Return-Path is
> for automated error messages *only*, not replies of any sort.

Can you give a link to the relevant internet standard please. I could not 
find it in RFC5322 (nor in RFC2822 which it obsoletes (nor in RFC0822 which 
it obsoletes)). RFC2369 which defines mailing list command specification 
header fields also says nothing about that field.

As far as I can tell, the standards define Reply-To and Return-Path but not 
Mail-Followup-To.

-- 
Owen Rees
========================================================
Hewlett-Packard Limited.   Registered No: 690597 England
Registered Office:  Cain Road, Bracknell, Berks RG12 1HN

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Dave Korn]

Owen Rees wrote:
> --On Wednesday, March 04, 2009 12:07:31 +0000 Dave Korn wrote:
> 
>>   Note also how all those paths have a Mail-Followup-To header pointing
>> at the list.  Any mailer that does not respect that when you hit Reply is
>> broken and does not comply with internet standards.  The Return-Path is
>> for automated error messages *only*, not replies of any sort.
> 
> Can you give a link to the relevant internet standard please. I could
> not find it in RFC5322 (nor in RFC2822 which it obsoletes (nor in
> RFC0822 which it obsoletes)). RFC2369 which defines mailing list command
> specification header fields also says nothing about that field.
> 
> As far as I can tell, the standards define Reply-To and Return-Path but
> not Mail-Followup-To.

  Yes, you're right.  Looking at the history, it's never made it to the status
of an STD, but there was an IETF draft proposal (which is actually one stage
more advanced than an RFC):

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt

and there are some more details at:

http://cr.yp.to/proto/replyto.html

  So it's only a de-facto standard.  Any mailer which doesn't want to
implement it is free to do so, but it is still incorrect if it uses
Return-Path for replies.

    cheers,
      DaveK

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Christopher Faylor]

On Wed, Mar 04, 2009 at 04:39:41PM +0000, Dave Korn wrote:
>Any mailer ...  is still incorrect if it uses Return-Path for replies.

FWIW, I think I'd notice if mail clients were using Return-Path.  I'd
see it in the sourceware log and, if it is occurring, it is not
occurring with enough regularity for me to notice it.

People misuing the "Sender:" field, OTOH, happens almost daily.  It
results in people sending email to gcc and gcc-owner.  The end result of
that is a little self-contained discussion amongst all of the people
cc'ed since I don't allow email cc'ed to *-owner to make it to a mailing
list.  At one point that was a sign of spam.  Nowadays it just is a sign
of a misconfigured mail client intent on spamming postmaster.

cgf

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Owen Rees]

--On Wednesday, March 04, 2009 16:39:41 +0000 Dave Korn wrote:

>   Yes, you're right.  Looking at the history, it's never made it to the
> status of an STD, but there was an IETF draft proposal (which is actually
> one stage more advanced than an RFC):
>
> http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-
> to-00.txt
>

To quote RFC2026:

2.2  Internet-Drafts

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving
   working document readily available to a wide audience, facilitating
   the process of review and revision.

   An Internet-Draft that is published as an RFC, or that has remained
   unchanged in the Internet-Drafts directory for more than six months
   without being recommended by the IESG for publication as an RFC, is
   simply removed from the Internet-Drafts directory.  At any time, an
   Internet-Draft may be replaced by a more recent version of the same
   specification, restarting the six-month timeout period.

   An Internet-Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism described in
   the previous section.  Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************


That, and the rest of RFC2026 makes it clear that a "internet draft" has 
lower status than an RFC - it is typically a proposal that may eventually 
turn into an RFC. On the subject of expiry:

draft-ietf-drums-mail-followup-to-00.txt
Expires: May 1998

It has not been followed up for over 10 years so I think that indicates the 
status of the proposal as far as the IETF process is concerned.

-- 
Owen Rees; speaking personally, and not on behalf of HP.
========================================================
Hewlett-Packard Limited.   Registered No: 690597 England
Registered Office:  Cain Road, Bracknell, Berks RG12 1HN

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Dave Korn]

Owen Rees wrote:
> --On Wednesday, March 04, 2009 16:39:41 +0000 Dave Korn wrote:
> 
>>   Yes, you're right.  Looking at the history, it's never made it to the
>> status of an STD, but there was an IETF draft proposal (which is actually
>> one stage more advanced than an RFC):
>>
>> http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-
>> to-00.txt

> To quote RFC2026:
> 
> 2.2  Internet-Drafts

> That, and the rest of RFC2026 makes it clear that a "internet draft" has
> lower status than an RFC - it is typically a proposal that may
> eventually turn into an RFC. 

  Oh, I remembered the order of progression wrong, I thought it was
RFC->draft->STD.

> On the subject of expiry:
> 
> draft-ietf-drums-mail-followup-to-00.txt
> Expires: May 1998
> 
> It has not been followed up for over 10 years so I think that indicates
> the status of the proposal as far as the IETF process is concerned.

  True, but that's not the whole story; the IETF standards process has always
been a lagged and idealised version of reality.  Still, I will reword my
earlier paragraph:

>   Note also how all those paths have a Mail-Followup-To header pointing
> at the list.  Any mailer that does not respect that when you hit Reply
> does not comply with common internet practice, but if it resorts to using
> the Return-Path header, it is completely incorrect.  The Return-Path is
> for automated error messages *only*, not replies of any sort.

    cheers,
      DaveK

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Owen Rees]

--On Wednesday, March 04, 2009 18:25:22 +0000 Dave Korn wrote:

>> draft-ietf-drums-mail-followup-to-00.txt
>> Expires: May 1998
>>
>> It has not been followed up for over 10 years so I think that indicates
>> the status of the proposal as far as the IETF process is concerned.
>
>   True, but that's not the whole story; the IETF standards process has
> always been a lagged and idealised version of reality.

<http://people.dsv.su.se/~jpalme/ietf/ietf-spring98-notes.html> contains an 
interesting note about Mail-Followup-To. It seems to have been one of a 
number of things considered by an IETF working group but with no agreement 
reached and the issue deferred to a later working group. It seems that the 
proposal was not revived in a later working group. If the proposal had been 
revived I would have expected it to appear in RFC5322 (October 2008) or for 
there to be something to indicate that it had been discussed.

A later internet draft 
<http://people.dsv.su.se/~jpalme/ietf/mailing-list-behaviour.txt> (Expired 
May 2003!) seems to be suggesting that the List-Post header defined in the 
Standards Track RFC2369 be used. The messages I get from various cygwin 
lists include the RFC2369 headers.

All that would be needed to make this work would be to update all mail 
clients to notice RFC2369 headers and offer an explicit "Reply to list" 
option. While doing that, perhaps we can update all mail clients to include 
an "Unsubscribe" button that appears whenever the user is viewing a message 
with the relevant RFC2369 header.

> Still, I will
> reword my earlier paragraph:
>
>>   Note also how all those paths have a Mail-Followup-To header pointing
>> at the list.  Any mailer that does not respect that when you hit Reply
>> does not comply with common internet practice, but if it resorts to using
>> the Return-Path header, it is completely incorrect.  The Return-Path is
>> for automated error messages *only*, not replies of any sort.

I am not convinced that Mail-Followup-To is common practice. Do most 
mailing lists insert it? cygwin apparently does but cygwin-talk does not 
nor do any of the other mailing lists to which I subscribe. Do the most 
widely used clients and webmail services support it?

Even if is is supported, the expired internet draft suggests that it is 
used to deal with "reply to all" which I would consider to be encouraging 
people to use a button that causes more problems than it solves and which 
ought to be abolished. The I-D appears to be suggesting that "Reply" be 
interpreted as "Reply to author" and it should use the Reply-to if it 
exists and From if not.

It is certainly true that using Return-Path for replies is wrong but there 
are very few circumstances under which it is used at all. The return-path 
line preserves the reverse-path information from the SMTP envelope; it is 
the envelope reverse-path that is used to report errors, the return-path 
line usually does not exist at the point where delivery errors are detected.

-- 
Owen Rees; speaking personally, and not on behalf of HP.
========================================================
Hewlett-Packard Limited.   Registered No: 690597 England
Registered Office:  Cain Road, Bracknell, Berks RG12 1HN

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Dave Korn]

Owen Rees wrote:

> All that would be needed to make this work would be to update all mail
> clients 

  <g>  That's probably the oldest meme on the internet.  "All we need do to
make X work is update every Y in the world".

> I am not convinced that Mail-Followup-To is common practice. Do most
> mailing lists insert it? cygwin apparently does but cygwin-talk does not
> nor do any of the other mailing lists to which I subscribe. Do the most
> widely used clients and webmail services support it?

  It's a client header, so the question is not whether other lists insert it
or not, but how well supported it is by common mail clients.  There's a list
at DJB's page (many years out of date) that mentions qmail, mutt, Gnus, Kmail
and SquirrelMail, and I spent five minutes googling and discovered that since
then it has also become supported by packages such as emacs and Thunderbird.
So it's reasonable to say that it has a fair degree of adoption.

  This is how the internet has always worked: someone proposes an idea, some
other people support it in software, everyone tries it out and if it works
good it gets widely-adopted.  The whole standardisation process is very much
an after-the-fact matter of documenting what the de facto standards are and
providing a gold-standard for interoperability so that any little misaligned
wrinkles between the various implementations can be ironed out.

> It is certainly true that using Return-Path for replies is wrong but
> there are very few circumstances under which it is used at all. The
> return-path line preserves the reverse-path information from the SMTP
> envelope; it is the envelope reverse-path that is used to report errors,
> the return-path line usually does not exist at the point where delivery
> errors are detected.

  The most widespread use is in NDRs, which add "Return-Path: <>" so that you
don't get bounces, loops and explosions of NDRs for NDRs for NDRs and so on.

    cheers,
      DaveK

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Owen Rees]

--On Thursday, March 05, 2009 13:27:56 +0000 Dave Korn wrote:

>   This is how the internet has always worked: someone proposes an idea,
> some other people support it in software, everyone tries it out and if it
> works good it gets widely-adopted.  The whole standardisation process is
> very much an after-the-fact matter of documenting what the de facto
> standards are and providing a gold-standard for interoperability so that
> any little misaligned wrinkles between the various implementations can be
> ironed out.

If the idea had been proposed this century...

>   The most widespread use is in NDRs, which add "Return-Path: <>" so that
> you don't get bounces, loops and explosions of NDRs for NDRs for NDRs and
> so on.

The Return-Path header would be used only if a message is being relayed via 
some non-SMTP mail transport that understands internet message headers and 
an error occurs in that non-SMTP environment.

In transit via SMTP messages SHOULD NOT contain a Return-Path header. The 
reverse path is carried in the SMTP envelope and delivery errors are 
reported using the SMTP envelope addresses.

-- 
Owen Rees; speaking personally, and not on behalf of HP.
========================================================
Hewlett-Packard Limited.   Registered No: 690597 England
Registered Office:  Cain Road, Bracknell, Berks RG12 1HN

Re: Your setting Return-Path to YOU in your cygwin@cygwin postings

[Morgan Gangwere]

... and why did this not get picked up by my "list-id:*@cygwin.*"
filter? there's no "reasonable" way to tell where the message is
going/coming from. Several MUAs i've seen have done a "Lets Assume On
Behalf Means We Send It To Random Addresses" -- such as Gmail at times
and Mutt.
Apparently, some MUAs take "on-behalf-of" indications as "send it to
the represented person" and not "send it to who sent it to me"

But That Might Just Be Me.


-- 
Morgan gangwere

"Space does not reflect society, it expresses it." -- Castells, M.,
Space of Flows, Space of Places: Materials for a Theory of Urbanism in
the Information Age, in The Cybercities Reader, S. Graham, Editor.
2004, Routledge: London. p. 82-93.