Subject: Re: [Maybe Spam] Re: Processed-By (or Transmitted-By) header concept

From: Danny Angus <[email-masked]>
Date: Wed, 29 Sep 2004 09:40:19 +0100

William,

<snipped some stuff I'm not going to disagree with/>

> So here is example of new format
> that I propose for this trace header:

Processed-By: odin.ietf.org (ip=[132.151.1.176])
   on-behalf-of [email-masked]
   original-envelope recepient=[email-masked],
    return-path=[email-masked], submitter=[email-masked]
   new-envelope recepient=[email-masked],
     return-path=[email-masked], submitter=[email-masked]
   changed-headers To, List-ID, Sender, CC
   process-type maillist (list-id=<ietf.ietf.org>) ;
    Tue, 28 Sep 2004 00:43:21 -0700 (PDT)
Original-To: [email-masked]
Original-Sender: [email-masked]

I think it is too much (header bloat, to coin a phrase), but I don't have
anything very constructive to say at this point beyond that fact that I
believe we should take every step to avoid duplication of information in
(or between) the envelope or(/and) the message headers.

Meaning that I would prefer (simply as a purist) a standard which mandated
existing optional behaviour, rather than duplicate the optional with a
mandatory alternative.
Instead of MAY add some piece of data to an existing header type, make it
SHOULD instead and already those people who implement the option will be
compliant with that new thing and messages won't bloat.

<more sniping..>

>The header is intended for use by MTAs doing automated procesing
>during transmission of the message, not by processes done by MUA.
>In fact the text might even state that if user-action forwarding
>is done than it maybe more appropriate to use Resent- headers
>instead of Procesed-By header.

Ok I already got this, it relates to .forward, .aliases and mailinglist
scenarios.
The only reason we believe that we can't use Resent headers...:

" Resent fields SHOULD be added to any message that is reintroduced by
   a user into the transport system.  A separate set of resent fields
   SHOULD be added each time this is done."

... is ...:

" They MUST NOT be used in the normal
   processing of replies or other such automatic actions on messages."

So if there is any requirement at all it is to handle
"automatic actions on a message by which that message is automatically
reintroduced _on behalf of_ a user into the transport system"

Hence I still maintain that "Reinserted" or "Reintroduced" would
disambiguate the purpose of the headers, and compliment "Resent".

<more snipping/>

I agree with your brief analysis of security, in particular with the point
that it would be no less trustworthy than any existing mechanism. However I
will continue to question the value of having such a big new burden (the
transport and processing of all that new data) without there being any
mechanism to ensure that it has any real added-value for the recipient at
all.

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: "Matthew Elvey" <[email-masked]>
Date: Wed, 29 Sep 2004 11:09:37 -0700

Pretty much what Danny Angus said:
I strongly prefer a standard which adds mandates that improve
consistency, and mandates existing optional behaviour, rather than
duplicates the optional with a mandatory alternative.
Instead of MAY add some piece of data to an existing header type, make
it SHOULD or MUST instead and already those people who implement the
option will be compliant with that new thing.

An example: 
Virtually all MTAs *that send mail directly over the public Internet*
(note the qualifier) already send a FQDN in their HELO(EHLO).  Mandating
an appropriate FQDN in HELO is something that many border MTAs already
enforce and would be good to codify in such a standard (which would be
forbidding something 2821 allows).  Broad CSV deployment will make this
a MUST on the public Internet whether a consistent
(forwarder/remailer/list) header info standard or the CSV standard
mandate it or not.
> <more sniping..>
s/sniping/snipping/ -Freudian slip?  :)   <joking...>

I see no evidence that the proposed header has any real added-value for
the recipient at all.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 29 Sep 2004 12:33:43 -0700 (PDT)

> option will be compliant with that new thing.

Did I ever say this was a mandatory or alternative to anything?

Just like information put in the received lines is not mandatory but
is considered to be "good behavior" so would this be good behavior
for systems that change source and destination addresses in transit.
It is definetly not going to be MUST at best SHOULD for old values
and MAY for new values (although i prefer SHOULD...)

I also note that information provided by the construct is currently
not available at all. This is its value, as it allows to see changes
made to email source and destination in consistant way. 

As far as amount of data, over 50% of emails (especially the shorter ones) 
are user to user (source to destination) direct and would not have this 
line, the other emails mostly pass through one or two forwarding hops 
which already add tons of Received and X- lines, at best this would add
25% extra header data to such emails. And in any case, all this data is
completely ignored by most end-users who are not techs and are not 
interested in how email got to them.

Also all email signing systems will add A LOT MORE data to emails just
by the fact that full signatures takes a lot more space. I'm not against
it and infact based on the amount of email data that ISP processe, it
seems that percent of SMTP traffic over overall traffic decreased (inspite
of increasing amount of spam). What happened is that ISP infrastructure 
has been upgraded with a lot bigger pipes both on the ISP networks and to
end-users who now often have DSL and cable and email use which was big
deal during dialup still remains but for DSL subscriber the real use
of internet is now P2P, MP3 downloads, gaming, HTML surfing with a lot
more graphics, etc. So we should not see ideas that cause increase in
size of emails as big deal for network infrastructure - it'll have
minimum impact on it and most it could is increase size of email box
storage but with advancement of storage devices and hard drives of
300GB now on the market (as opposed to 30GB 5 years ago), this also
woule have no serious impact.

-- 
William Leibzon
Elan Networks
[email-masked]