ietf-asrg
[Top] [All Lists]

Re: [Asrg] 1. Inventory of Problems - SMTP

2003-12-20 23:19:41
Dave Crocker wrote:
> 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.

So are you implying that we shouldn't worry about the SMTP transaction
at all, and concentrate on the message content itself, kind of like the
DK proposal?

While spam itself is an end-to-end problem, the abuse of the hop-by-hop
protocol is one of the reasons why spam happens. For example, in Ethernet the actual cables between different network segments are hop-by-hop. Someone slicing a cable at that point can introduce malicous traffic into the system, the same way somebody messing with a single SMTP hop-by-hop transaction can introduce spam into the network.

I think we need to address both issues of hop-by-hop protocol security, and end-to-end user issues. I do have your original suggestion in mind, and I am working on a document about email problems from the point of view of human communications in general. However, Alan's document concentrates specifically on SMTP.


> 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?

We do not want to reject all email from unknown senders since any
anti-spam system that is deployment needs to be adoped gradually.
Therefore, a completely unknown sender will be given a higher value in
the filter, as opposed to a known sender that will be given a lower value. Alan's document was refering to LMAP where even a known sender that uses LMAP is not necessarily trusted.

Yakov




-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I want to know G-d's thoughts... the rest are details" (Albert Einstein)
-------


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg