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 of the sender and may not reflect the
opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the
presence of computer viruses.
**************************************************************************