ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - A Brief Defence of "Pull"

2003-10-01 03:02:32
      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