Re: RFC 1123 and SMTP

[Bob Braden <[e-mail]>]

> From [e-mail] Thu Nov  5 22:17:42 1992
> To: [e-mail]
> Subject: RFC 1123 and SMTP
> Cc: [e-mail]
> Date: Fri, 6 Nov 1992 16:17:47 +1100
> From: George Michaelson <[e-mail]>
> Sender: [e-mail]
> Content-Length: 1915
> X-Lines: 48
> 
> 
> I'm doing alpha testing work on PP 6.3. and have encountered some problems
> with interop between this product and PMDF 4.1 on Vax/VMS.
> 
> (1)	PP has a "strict" mode where it refuses mail if the header has
> 	no From: or Date: line.
> 
> 	The readings of RFC822/821 and 1123 which allow one to take
> 	this decision are somewhat casuistic. It's certainly not explicit
> 	by words of the type:
> 
> 		"a valid RFC822 message MUST have a Date: line and MUST
> 		 have EITHER a From: line or a Sender: line"
> 
> 	But instead by readings of the BNF which can say "since the
> 	BNF notation for 'optional' is used for alternate values here,
> 	It suggests that one of them must be present" 
> 
> 	I think this is a laudible aim. I also think its pretty untenable
> 	given the current behaviour of some other mailers. I really don't
> 	want to buy into a religious war, And I suspect both PP and PMDF
> 	developers are close to going nuclear on this one. 
> 
> 	-For example, Eudora will only send a Date: line if the MAC in
> 	question has the localtimezone defined. Many MACs routinely don't
> 	do this, and thus send mail which PP can interpret as "illegal"

George,

I would say that sending mail without a date: field or without a from:
field is a thoroughly rotten idea, and I would try to beat up any
implementor responsible for such rubbish.  But I think this rests on
common sense (not casuistry, I hope!)  rather than on any formal
requirement in either RFC-1323 or RFC-822.

One fundamental principle (ah, here comes the casuistry) is liberality
in reception, so the receiver ought to accept mail without these
fields.  However, if the implementor wants to have a user-selectable
mode that is hard-nosed, that doesn't seem so bad to me, if it results
in a blizzard of error messages descending on the guilty sender.

I suspect we are having an agreement here.

> 
> (2)	It appears that PMDF generates Headers when relaying mail that
> 	append Resent- or Relayed- or Redistributed- to the existing 
> 	Header.

Do you mean 'relaying', in the strict sense of RFC-1323?  1323 tries very
hard to discourage relaying.

> 
> 	RFC1123 refers to a requirement to *prepend* Recieved-via lines,
> 	and also refers to "adding at the top of the message" somewhere
> 	else in the body of the text. 
>

I assume you refer to 537(B), in the context of gatewaying into/out of
the Internet.  This requirement is only intended to enforce the
Received: line protocol specified in RFC-821, to allow diagnosis of
problems.
 
> 	If the intent is that all relays prepend additional header lines,
> 	I think this needs to be more explicit.
>

?? I don't understand this comment.
 
> 	-This one is causing PP to reset the sender/from fields, presumably
> 	on the assumption that they will be set subsequently from the
> 	original header values. Since the fields have been appended and
> 	thus follow the From: line, this destroys information. -I suspect
> 	PP is wrong, but again I may misunderstand the intent of RFC1123.

Huh?  The Received: lines are only comments, for tracing the route the
message took.  It should have nothing to do with the sender/from fields.
Perhaps they are being munged as part of the gatewaying functio?

Bob Braden

> 
> 
> Any adjudicating remarks greatfully recieved...
> 
> -George
>