> I definitely am used to thinking of protocols as residing at boundaries,
> pretty much by definition, and I hope we are VERY careful about
> maintaining the distinction between the abstract architecture, versus
> concrete implementations.
I agree. However in the ugly tables you say that the envelope is created
by the MSA, but from a the protocols point of view (and from the point of
view of most software these days) the MUA must create the envelope in
order to be able to talk to the MSA.
saying anything that means the msa always creates something is a writing
error. my intent is to say that it enforces things and *might*
create/modify things, in order to do the enforcing.
How can it enforce the envelope recipient list if the mesage arrived via
RFC 2476?
I'm inclined to talk about message submission in the abstract, with some
functions typically implemented by the MUA (e.g. preparing the envelope)
and some by the MSA (header fix-ups and policy enforcement).
"envelope":
User-to-User is the stuff that the originator creates with the intent
that it be consumed by the recipient.
In contrast, the handling information is created for consumption by the
handling service or by the handling service, primarily for consumption
by email operators or for operational analysis.
I conclude that there's no detailed, precise definition of which parts of
the message header might constitute "handling information", and might
therefore constitute part of the Crocker-envelope. The Finch-envelope, on
the other hand, is well-defined and commonly understood.
When a message is Resent- are the trace fields from the original
message now part of the "user-to-user message" or not?
Good question. I do not know what constitutes "prevailing" practise.
My own view is that old trace information should be dropped, since a
re-send is creating an entirely new message.
2822 implies preservation of all the trace fields (including previous
received and resent information). Most implementations, however, follow
822 which only allows for one level of resending. It's common for them to
preserve the old trace fields except that they are prefixed with X-.
"gateway"/"firewall":
We need a word to talk about the parts of the MHS that might mangle
messages.
Historically, the email term for an entity that transforms content is
'gateway'.
A gateway is an entity that does message (semantics) conversions.
I seem to remember discussing this with you in the past. I asked whether
MTAs that do content mangling were gateways and you said that they
probably don't count because they don't gateway into a non-internet MHS,
and that "MTA firewall" might be a better term.
I like the idea of distinguishing between gatewaying and (for want of a
better term) firewalling. The former seems to imply semantics-preserving
transformations (or the closest possible approximation thereto), but a
firewall might make all sorts of content-mangling or -destroying changes.
Relative to the underlying handling service, when there is a gateway it
usually take formal delivery creates a new message.
Do you mean "final delivery" here in the 821 sense, or do you mean the
kind of responsibility hand-off that 1123 and 2821 describe? From the
point of view of "emulat[ing] a continuattion of the handling service" I
think it is better to view final delivery as an accident of implementation
rather than part of the architecture. A gateway is more likely to be
implemented in a manner similar to a firewall-MTA than off the back of an
MDA.
As I said, what makes gateways interesting -- besides the impossible
task of trying to preserve all the semantics -- is that it is possible
that they emulate a continuattion of the handling service, through the
gateway. This is difficult and I believe it is rare.
I understand that Exchange and Notes etc. work in essentially this way,
which goes a long way to explain the terrible mangling that they cause.
I am not used to having the term firewall refer to the job of content
conversion. I am used to it strictly meaning a security function of
detecting attacks and rejecting them.
Yes, I agree that the term doesn't fit very well. The functions I want to
describe with the word are mostly security-related but some of them are
more or less technical policy.
dropping/replacement of attachments which violate some restriction which
might be security-related (e.g. no executables, virus infection) or might
be for some other policy reason (e.g. no HTML messages on a mailing list,
or no graphics, or whatever).
adding footers, such as list unsubscription instructions or stupid legal
disclaimers or ads
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOLE LUNDY FASTNET: NORTHWEST 4 BACKING WEST OR SOUTHWEST 5 TO 7, PERHAPS
GALE 8 LATER. RAIN LATER. GOOD BECOMING MODERATE.