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