At 19:26 21-08-2007, Douglas Otis wrote:
Why change? When a sender is suspected of spamming, the receiving
MTA could limit exchanges to Transfer By Reference instead of issuing
an ultimately more expensive refusal or message acceptance. In the
case of TBR, SMTP would be limited to just exchanging an HTTP message
reference within the SMTP envelope. This separate HTTP channel
provides both delivery confirmation, and ensures the validity of the
reference.
This would also apply to the case of unknown senders, I gather. If
so, we'll see more Transfer By Reference (TBR) messages. We won't
have the entire message to make a proper assessment. The receiver
could however use a reputation system or other means to tell whether
he/she wants to accept the message from the sender.
As the message reaches the MDA, the MDA would have the option to
proxy access via BURL, fetch the message and revert to a normal SMTP
form, or convert the reference into a pseudo message compatible with
MUAs where recipients decide whether a message is to be accessed.
TBR does not prevent spam, however it significantly lowers the
recipient's burden and provides a simple means for avoiding unwanted
or spoofed messages. Details will follow in a draft.
Your proposal pushes storage costs to the sender side. It does
introduce a delay in the communication which may put off some people
who have the expectation of "IM".
Instead of using HTTP, the retrieval could be requested at the
recipient's end by having the MUA send a message to the receiver's
server. That server would then initiate a transaction based on the
sending address to request delivery of the complete
message. Compared to your HTTP channel method, there's much more
delay here. But we don't require a direct path to retrieve the
message content. There is another disadvantage. The sending server
cannot tell at the outset whether the final hop will only accept this
type of transaction instead of a normal delivery for the sender/receiver pair.
The cost of deployment is high as the above requires servers and MUAs
to be upgraded. There's also the question of abuse which hasn't been explored.
Regards,
-sm
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf