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

William,

> 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...)

My problem is that no matter how finely crafted this may be it will be of
very little practical use,
far more valuable in this role would be the normalisation, through
clarification and mandating, of existing optional compliant behaviour and
non-standard best practice.
I'm arguing exactly that we _should_ be replacing MAY with MUST or SHOULD
in existing specifications before creating a new header with a broad scope
which I suspect overlaps to some degree with many other _optional_ parts of
existing rfc's at various stages.

The net result would be that there would be a well supported set of
standards created from the de-facto behaviour of the majority, and probably
a clearly identifiable gap which may indeed need addressed in terms of new
specifications for new headers.

What I fail to see the benefit of is a new trace header that duplicates
existing information, involves the transmission of significant extra data
(by significant I mean that we are considering doubling the header involved
in every change), is not mandatory and would in practice be unreliable for
all but the last hop.

> 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.

I can see why you think this, but I would contend that if Received and
Resent headers included the full range of fields available to them and
HELO/EHLO contents were standardised and mandated a far more useful (but
not complete I grant you) picture would emerge.

>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.

My point is that this information increases network traffic and MTA load
for _little_ gain.

> 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.

But here there is a quantifiable gain. This extra data guarantees quality,
signature data provides reliablity and enables security and trust.

> 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.

Somewhere in every system's people is a guy who's job it is to cost and
justify bandwidth provision, home users buy what is available, business
users purchase bandwidth to satisfy their need, if that need is increased
as a result of increased message header sizes you'd better be prepared to
justify that increase in terms of security, savings available elsewhere, or
fixing a problem.

I mean no disrespect to you, I wouldn't be saying these things if I felt
that your proposals were way off beam and lacked merit, I have ideas of my
own which are complimentary to and compatible with your overall plan, and
they also benefit from enhanced traceability so you could say that I
understand the reasons behind this requirement. But I diverge from the
point, more of this later.
In the meantime however, I believe that the answer to this part of the
problem is to build consistency into the specifications of the headers
which already exist, and not to introduce a new one until we have found the
minimum data we require from it that we don't have the opportunity to
calculate from data contained elsewhere.

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 o
 f the sender and may not reflect the opinions and views of The Student Loans Company Limit
 ed.

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

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