Re: Your setting Return-Path to YOU in your cygwin@cygwin postings
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Your setting Return-Path to YOU in your cygwin@cygwin postings
by Owen Rees
::
Rate this Message:
--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
by Dave Korn-6
::
Rate this Message:
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
by Christopher Faylor-8
::
Rate this Message:
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
by Owen Rees
::
Rate this Message:
--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
by Dave Korn-6
::
Rate this Message:
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
by Owen Rees
::
Rate this Message:
--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
by Dave Korn-6
::
Rate this Message:
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
by Owen Rees
::
Rate this Message:
--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
by Morgan Gangwere
::
Rate this Message:
... 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. |
| Free embeddable forum powered by Nabble | Forum Help |
