Subject: Redirected Trace header draft (was Processed-By or Transmitted-By header concept)

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 2 Nov 2004 13:49:32 -0800 (PST)

I would like to receive comments and open discusion on the following 
document which I expect to publish as Internet Draft after the IETF 
meeting in Washington
 http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre02.txt

The draft describes concept that we right now refer to as automated forwarding
by new name email "redirection" (along same lines it refers to mail systems
that do the this forwarding as "Mail Redirection Agents" aka MRA) and 
describes "Redirected:" header (which I previously was going to call 
Processed-By) for purposes of tracking when redirection takes place and  
providing information on what changes are done there to SMTP 2821 
parameters and SMTP 2822 headers during redirection process.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 03 Nov 2004 19:10:34 -0800

On 11/2/2004 1:49 PM, william(at)elan.net sent forth electrons to convey:

>I would like to receive comments and open discusion on ...
>draft-leibzon-emailredirection-traceheaders-00pre02.txt
>  
>
This looks good.   It adds information that may well be useful for 
debugging and investigating, without adding tons of redundant info.

An earlier criticism of mine wasn't that it adds tons of info, but that 
(I thought) it added redundant info - that it duplicated info that was 
already there in 'Received:'.  Looking at it more closely, now in draft 
format, I see that this isn't the case.  It's not redundant.   :)

I'm going to give another swing at explaining why I feel there are 
SHOULDs that should be MUSTs in this spec.
At a high level, consider SMTP as an example of a set of specs.  The 
purpose of SMTP is to allow e-mail to flow in an interoperable way 
between systems. If an implementation follows all the MUSTs in the specs 
for SMTP, then it will be capable of accomplishing this purpose.  (Or at 
least that is the intent of the specs.) 
In general:
If an implementation follows all the MUSTs in the specs for the 
implementation, then it will be capable of accomplishing the purpose of 
the implementation.
Or at least I think that's the way it should be.
The purpose of the Redirected spec is to enable interoperable 
traceability of an automatically forwarded email by providing all the 
key information that the forwarder changes or replaces.
The general case should apply:
If an implementation follows all the MUSTs in the spec for the 
implementation, then it will be capable of accomplishing the purpose of 
the implementation.

Using  wording from RFC 2119 defining SHOULD, let me state: I can't 
think of a valid reason in any particular circumstance where an 
implementation's implementer who desires it to be compatible with this 
spec would need to ignore the particular items suggested by (e.g.) the 
first three SHOULDs in the spec.
Also, the goal of the spec can't be met if these SHOULDs aren't 
followed, so they should be MUSTs.   If an implementer doesn't want to 
enable "interoperable traceability of an automatically forwarded email 
by providing all the key information that the forwarder changes or 
replaces" then fine, but it must be clear that isn't compatible with 
this spec. Therefore, these SHOULDs must be MUSTs.

Does this make sense to you?  Am I mis-reading 2119?

(Said another way: Some servers admins do not wish them to send or 
receive e-mail. Their purpose does not include accomplishment of that 
goal.  So they don't support the RFCs defining SMTP.  They violate the 
MUSTS of these RFCs.  This isn't a problem.  It *doesn't* follow that 
the MUSTs of these RFCs shouldn't have been SHOULDs or MAYs!)

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 4 Nov 2004 00:56:23 -0800 (PST)

> >draft-leibzon-emailredirection-traceheaders-00pre02.txt

I appreciate your feedback. New version based on all the feedback received 
today and fixes that I made is now available at:
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre03.txt

> SHOULDs that should be MUSTs in this spec.

Using MUST makes it appear that I'm making it an immediate requirement 
for all systems involved in forwarding/redirection. In fact it will
still be just a new optional trace header for recording what happened
during redirection. 

> the implementation. Or at least I think that's the way it should be.
>

I'm going to try to follow your suggestion and change first three SHOULD 
to MUST because if somebody does follow this document, they really should
be doing it right (i.e. MUST). But i'll emphasise again that document in 
itself and new header is not any more requirement then current Received
header - its just a good idea. As such I believe in the end I'll be
forced to change language back to SHOULD when the draft is discussed at
ietf-822 and other lists.

> Does this make sense to you?  Am I mis-reading 2119?

Yes it does. But Standard Track RFCs with MUST mandate required behavior
and in this case it would be required behavior of the forwarding systems 
and current forwarders don't do it so we really can't make it a MUST 
although as I said already if they are tryingto follow this spec, then
for them it should all be MUST.

-- 
William Leibzon
Elan Networks
[email-masked]