Re: RFC 1123 and SMTP

[George Michaelson <[e-mail]>]

I find myself doing a lot of fence-sitting.

On the one hand, I like the guiding rule of being lax in what you
accept and firm in what you emit. By these principles, both PMDF and PP
can be seen as being a little wrong at times, and a little bit right.

However Down in the PP trenches, my cohorts still seem to believe the
BNF of 822/821 is quite explicit in mandating (nay, requiring) Date and
[From|Sender] in header. And equally, allowing laxity of emission to
persist in common and popular code is going to make things worse in the
long run. Mail is not (usually) a one-way exchange, and the less work
required to reply, the better. As somebody has pointed out, All it does
is force all the UA to be more clever to detect an originator.

I think the Date/From dogfight is bigger than my feeble cortex can handle
so I shall back out of this area: PP can be tuned to be lax or firm so
I can have the best of both worlds. Having said that, I also feel a firm
interpretation of the gospel has to be taken some time before the
heat-death of the universe.

The Relayed- stuff is sort of mixed up in my mind. I don't entirely understand
the strategy that lies behind what PP does, but the code is quite firm in
expecting ALL Relayed- Recieved- and Resent- to proceed the originating
systems header fields. I suspect the behaviour following on from parsing
one of these is a bug, and will be hassling pp-authors on that basis.

However, I think their assumption may make sense. If all of the
intermediate parties to any relaying/forwarding/munging going down as
the bits dance down the cables only place their new information at the
FRONT of the list of header fields, then the changes to a header are
deterministic (and furthermore only additive), and you can expect to be
able to read backwards from the originating systems fields to trace
each step of the path.

If somebody (like PMDF appears to) is placing some of these AFTER the orginal
header fields, tracing is going to be a lot harder. I also find the idea
of messing around between the header and the message body rather distasteful. I
don't want anybody stuffing hands down beneath MY topcoat to add another
waistcoat or two. If I need extra wrapping, add on the outside!

Ok, now the counter argument:

I read other parts of the dialogue(s) to mean nobody who isn't in the game
of converting mail with good cause (relaying between protocols or
encodings, transiting from delivery paths to message store) should be
doing much more than adding trace info, so my reference to munging may
be seen as casual blasphemy.

Alas, Since PMDF is bridging the world of colon(ic) irrigation that DEC
persist in using, and the mail in question has actually been passed
from TCPIP/SMTP, through PMDF, into VMSmail, into a 

	set forw/user="re-inject into SMTP" 

clause, and thus back out of the DEC UA (into PMDF as MTA again) There
are at least two places where PMDF authors can claim the mail has
transited a real boundary, permitting them to play with the header as
they see fit.

	-George