Re: Processed-By (or Transmitted-By) header concept

On Fri, 2004-10-01 at 02:40, william(at)elan.net wrote:
> On Fri, 1 Oct 2004, Danny Angus wrote:
> 
> > > From a purely engineering point of view, it is nice and
> > > reasonable. But for producing actual outputs, I doubt you will be able
> > > to update RFC 2821 and 2822 on Received headers in the short term. Or
> > > to modify the code of several MTAs.
> > 
> > Fair point.
> > What I'm actually proposing, though, is that a new, stricter, specification
> > for Recieved(etc) be written as an interim measure which would not obsolete
> > 2822 but compliment it. Eventually the next iteration of 822 et al could
> > obsolete our rfc and adopt the chnage.
> 
> I really don't know if it helps but for some time I've been gathering data 
> on errors in Received lines and which MTAs are compliant and not. The 
> results I have so far is that virtually all MTAs under certain conditions 
> (and some always) add Received lines that are directly syntatically 
> incompatible with RFC2822. And in any case fixing Received is completely 
> diffirent task that will probably take quite a bit more effort even if 
> new draft is published.
> 
> Plus as far as which of the data that goes into Processed-By is also in 
> Received, there is only one value - envelope recepient (which is "for"
> clause on received line). The envelope from (returnpath) is added in this 
> from by one mailer:
> 
> Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131])
>         by above.proper.com (8.12.11/8.12.9) with SMTP id i918GsKb059836
>         for <[email protected]>; Fri, 1 Oct 2004 01:16:55 -0700 (PDT)
>         (envelope-from [email protected])
> 
> But if you look at RFC2822 it says that syntax of Received is:
>  received  =  "Received:" name-val-list ";" date-time CRLF
>  date-time  =  [ day-of-week "," ] date FWS time [CFWS]
>  time = time-of-day FWS zone
>  zone = (( "+" / "-" ) 4DIGIT)
> 
> Based on above addition of "(envelope-from [email protected])" at the end
> of Received after time violates RFC2822, so we should not promote this 
> behavior for the future. In addition I do not think it is appropriate
> behavior to mandate adding "envelope-from" to every received line, its
> of interest to know the value when it has changed, but repeating it every
> time is waste of header space (did you call that "header blotting"?).
> 
> Additionally Processed-By provides for new "Original-*" headers for 
> recording previous values of Sender, CC, Reply-To, List-ID, etc. There
> is no equivalent for this in current SMTP specs and if you send email
> to mail list, it'll rewrite original Sender and its value is lost to
> recipient. If you have message that went through more then one mail list, 
> you'll only see info about last email list, as each would want to add
> the same list of headers overriding previous values (and sometimes
> mixing it up which is even worth). When you add forwarding to the mix
> the situation is even worth. 
> 
> So I'm sorry but I really don't see how Received line is going to help
> with all this, we do need new specification. And as far as Received
> line - its also a good idea idea to write something up to explain to MTA
> writers what they need to do with it, but this is separate task.
> 
> > I think that most MTA's already validate and publish some degree of
> > optional information in received headers
> Hahaha (sorry it the "most" part and "validate" that got me...)
> 
> As far as optional information - entire Received line is optional 
> information and at best you can hope to find EHLO name and
> ip address of the SMTP Client and even that is not for certain.

There has been some consideration given this within CSV.  It would be
helpful to mark the Received header indicating a successful validation
using the CSV record.  This would assist in locating the weak-link and
perhaps to deprecate message assertions as a result.

Once the HELO domain has been validated, then the address list technique
of SPF and Sender-ID can be abandoned and replaced by the use of a name
list.  This name list approach is much more expedient and safer.  

Any reputation assertions should be based upon the HELO information and
not the mailbox domain.  A name list referenced by the mailbox domain
will allow rejection of obviously spoofed mail or alert the receiver of
this potential.  The mailbox domain identity carried through the mail
channel is not strong enough to safely base negative assertions.  If to
stop the problem, stop it at the source.  The source is the mail
transfer agent, and any name involved with blocking must be constrained
to exclusively identify the administration of the mail transfer agent.

-Doug