In essence, this would be like asking recipients to go to the
remote post office box for each and every sender, when they wanted to
pick up mail. On the Internet, this isn't as bad as it would be in
the real world, but it would still be exceptionally painful.
I'm not quite sure which "recipient" you mean: I was referring to the
receiving MTA in a mail exchange between domains with no prior trust
relationship. The receiving MTA would pull the message from the sending MTA
and deliver it to the message repository (subject to policy) in a way that is
transparent to any agent or person beyond that point.
The analogy you give is technically accurate, but you could also describe the
existing situation as like hanging around in a well-advertised location all
day and night just in case someone wants to talk to you. It makes it sound as
though a person is being inconvenienced, when all we are talking about is a
computer program (the MTA).
Until you can provide mechanisms that have strong cryptographic
authentication that securely tie in a particular notice to a
particular message body, and you can ensure that it is physically
impossible for someone to accidentally or intentionally swap message
bodies, I don't see where you can get this mechanism to work.
I don't see that this argument applies. It is possible to require the sender
to commit to a particular message by including the SHA1 digest (or similar)
of that message as part of the callback token, but I don't see that it gains
us anything in this instance. The receiving MTA is expecting some arbitrary
message. It is possible, in this instance, that the message could be changed
between the receiver being told about it and actually fetching it, but what's
the associated threat? I changed this message several times before anyone
else saw it -- what's the difference?
There's a reason why the envelope is delivered along with the
message body, even if the entire envelope is a forgery (beyond the
source and recipient addresses). For MTAs that split the envelope
from the message body, they have to deal with a two-phase commit
problem to keep the two in sync. That makes the problem
significantly more difficult to deal with.
I think we may be confusing our vocabulary here. I understand "envelope" to
mean all the metadata associated with the SMTP dialogue, and "message" to
mean the information passed in the DATA phase of SMTP, which is supposed to
conform to STD 11 (RFC 822 and its successors). The message consists of a
"header" (or "header fields") and a "body". This is the terminology used by
RFC 2822 (see sections 1.1 and 2.1).
I can't comprehend your remark, "even if the entire envelope is a forgery
(beyond the source and recipient addresses)", except by assuming that you
meant "message header" rather than "envelope", since the "MAIL From:" and
"RCPT To:" addresses are basically all there is in envelope data. But if I
make that assumption, I can no longer see the relevance of your remark to my
argument at all, since I've said nothing about separating the message header
from the message body: the whole message is pulled in a separate session.
Perhaps you could explain the nature of the two-phase commit problem in a
little more detail?
Regards,
TFBW
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg