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

From: Danny Angus <[email-masked]>
Date: Fri, 1 Oct 2004 09:16:53 +0100

> 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.
So.. an MTA could continue to implement rfc2822, and optionally implement
our new RFC by constructing the headers with as much optional information
as is incuded in 2822 and required by us.
I think that most MTA's already validate and publish some degree of
optional information in received headers, and some of them can have this
behaviour changed by config alone.

d.

***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 1 Oct 2004 02:40:29 -0700 (PDT)

> 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-masked]>; Fri, 1 Oct 2004 01:16:55 -0700 (PDT)
        (envelope-from [email-masked])

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-masked])" 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
recepient. 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 overiding 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.

> 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 
informatio and at best you can hope to find EHLO name and
ip address of the SMTP Client and even that is not for certain.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

---

From: Douglas Otis <[email-masked]>
Date: Fri, 01 Oct 2004 10:46:46 -0700

On Fri, 2004-10-01 at 02:40, william(at)elan.net wrote:
> recipient. If you have message that went through more then one mail list, 
> the same list of headers overriding previous values (and sometimes
> information and at best you can hope to find EHLO name and

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