Yakov,
>> 3. The sender can request that the message be forwarded to (almost) >> anyone else. >> >> SMTP isn't a "user to user" protocol. It's a "submitter to MTA" >> protocol. In the case of open proxies, the MTA may be abused to >> re-send the mail to anyone on the net.
YS> Isn't SMTP an MTA-to-MTA protocol, with SUBMIT being the "submitter to YS> MTA" protocol?
yes, although that is recent, and most poster-to-MTA interactions do use SMTP. However access control is now typical, so the problem of open relaying is solved technically. Whether the solution is used is not a problem with SMTP.
>> 6. no negative feedback >> >> TCP has congestion control. ICMP "port unreachable", etc. >> >> When SMTP messages are thrown away, they're often done so by the end >> user. The recipient MTA usually doesn't know, and the originating MTA >> doesn't know. So in the absence of negative feedback, spammers >> increase their sending rates, in the hope that some messages will get >> through.
YS> This also has to do with the fact that the body of the message and the YS> SMTP transaction are separate from each other.
Huh?
1. SMTP is equivalent to a link-level, point-to-point protocol. As such, it has plenty of negative feedback and congestion control. The larger mail service is a classic datagram model, like UDP. And, no, it has no congestion control. However as one contemplates this problem, keep in mind the challenge of doing meaningful end-to-end congestion control in the face of multi-day latencies.
2. I think folks are trying to make the underlying transport service be responsible for higher-level, user-to-user problems. Remember that spam is a social problem, not a technical one. So, worry about the end-to-end object/envelope, rather than the hop-by-hop transfer protocool.
>> e.g. Messages from unknown senders should be treated with great >> suspicion. Any and all available information should be used to >> determine how to process the message.
YS> A good example would be giving a higher value to unknown senders in YS> SpamAssasin.
How is this different from whitelisting?
How is it affected by spoofing?
d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg InternetWorking <www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>
_______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg |