RE: Is Return-Path as available as we think?

-----Original Message-----
From: Justin Mason [mailto:jm(_at_)jmason(_dot_)org]

Ernesto Baschny writes:

[snip]

BTW a very helpful addition to support MUAs and MUA-level filters
getting at the envelope from, would be if this was added to the
Received headers, e.g.

  Received: from portent.listbox.com (portent.listbox.com [208.58.1.195])
      by amgod.boxhost.net (envelope-from
      <owner-spf-discuss(AT)v2.listbox.com>) (Postfix) with ESMTP id
      12CE931024F for <jm(AT)jmason.org>; Wed, 28 Jan 2004
      08:54:19 +0000 (GMT)


I am so strongly against that. There is already a standard header to do
just that! Why reinvent it?

This would allow filters like SpamAssassin to pick up the envelope-from
used at each step of the chain, which is very valuable especially when
intermediate steps tend to rewrite it.  (For example, fetchmail makes some
incorrect assumptions, and will add an *incorrect* Return-Path header if
an X-Envelope-From header exists, even from an earlier handover.)

From RFC-2821 section 4.4: (I changed the uppercase sentence to upercase)

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.

There can't be an incorrect header, because you know YOUR system adds
a true one and it is ths FIRST (in fact the first line in many cases).

Why do we have to invent a standard when one exists, and it's good
enough? All we need is to ensure compliance by the current array of
popular MTAs, and that's that.

I suggest anyone suggesting anything added to MTAs to first READ THE
F'ING RFCS and check if their suggestion is at all relevant. This is the
third time I quote the same paragraph from the same RFC in this thread.
Don't make me do that again, please.

-- Arik

**********************************************************************
This email and attachments have been scanned for
potential proprietary or sensitive information leakage.

PortAuthority(TM) Server
Keeping Information Inside
Vidius, Inc.
www.vidius.com
**********************************************************************

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§ÅvÂ¼ð¦¾Øß´ëù1Ií-»Fqx(_dot_)com