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(_dot_)knowles(_at_)skynet(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg