[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 8:00 PM +1000 2003/10/01, Brett Watson wrote:


 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.
Okay, then. Remind me what the benefit is that you're trying to achieve?

Pure envelope decisions could be made before the message body is transmitted, regardless of how that transmission occurs. No change is required to the protocol.

Message content decisions can only be made once the message content has been received, regardless of how that transmission occurs. Again, no change to the protocol is required.

Greylisting does not affect these issues in any way, nor is it impacted by them.

 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?
You give spammers a new avenue of attack. All they need to do is compromise a "message pull" storage server, and replace the message bodies there with their spam. The notifications that were originally sent out were perfectly legitimate, but the message bodies that the recipients get are bogus.

You have to be able to guarantee that the recipient (MTA) can determine whether or not the message body has changed since the notice was sent.


Moreover, this requires that the stored message bodies can only be used unidirectionally.

Otherwise, once you've posted your reply the sender could then change the text it appears that you're replying to, which might change the whole tone of the discussion -- instead of violently opposing cruelty to animals, you are instead seen as violently opposing respected charities beneficial towards animals.


This also implies that the original stored message content is unrecoverable by the recipient, if they didn't check the message before the content changed. All they'd have is an SHA-1 digest that tells them about a message that supposedly existed for them, but it is no longer available.

You might be able to create a chaining mechanism, which says that message body with hash X was replaced by message body with hash Y, but unless you require the "message pull" storage server to keep a copy of each and every version of each and every message body, you would have no way to know what was in any of the previous versions of the message.

 Perhaps you could explain the nature of the two-phase commit problem in a
 little more detail?
Sorry, I was thinking that you were talking about splitting the headers from the message body. My bad.

--
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg