> 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?
submission has an envelope, just like smtp, since they are essentially the same
protocol. so the question is what it means to 'enforce' existing fields:
1. there might be site constraints on the rfc2821.mailfrom values that a
submitter can use. (the fact the submission is expected to be an authenticated
process makes enforcement of this feasible.)
2. Again, because submission is authenticated, there can be enforcement on
rfc2822.from and other fields.
3. and the specific that you ask about, recipient list, is certainly not likely
to need enforcement. but the recipient list wasn't singled out in the mail-arch
doc.
what's the problem with mere enforcement? why must the msa create fields?
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).
well, the intent was to permit the exact venue for some of these functions (mua
vs. msa) to be fluid.)
"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.
not by crocker (...)
I had not thought of my assessment on this as being particular to me, although
i know there is variation within the community. I do not have any sense of a
solid consensus within the community. If I did, I'd use it.
> 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).
sigh. yeah. it does.
"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.
well, i certainly could imagine having said that at some point. the history of
email is not filled with care or precision about functional boundaries. these
days i'd rather keep these things as simple as possible. it's the only way we
are ever going to a) get clear about things, and b) stand any chance of getting
meaningful conformance.
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.
My own preference is to have a single manglers, and then try to define
sub-categories. So, a security gateway is a firewall. a mail protocol gateway
is something like x.400/internet.
> 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.
Let me see if I can get away with making this simple: final delivery is when a
DNS success message would get generated...
Back when I was arguing that imap was post-delivery and pop effected delivery,
folks were pointed is citing the DSN generation event as a discriminator. So I
am hoping it can help clarify this situation too.
A gateway is more likely to be
implemented in a manner similar to a firewall-MTA than off the back of an
MDA.
depends.
> 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.
attempts to to application gatewaying that preserves interesting end-to-end
properties is very tough.
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).
yeah. i take your point.
interesting modeling challenge.
adding footers, such as list unsubscription instructions or stupid legal
disclaimers or ads
well, that's not a firewall. that's a mailing list and i model that as a
separate user, creating a new message...
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com