Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Jun 2005, Dave Crocker wrote:

> Keith,
> 
> >  it's possible to have open relays that don't contribute to spam.  but
> >  those relays need to employ some other means, e.g. rate limiting, to
> 
> Rate limiting is a relatively recent technique.  Though very useful it has...
> ummm, limited applicability.

I tried a "rate limiting" freeware a couple years ago. It didnt' work,
largely due to very poor programming. It had no locking. The programmers
didn't seem to understand that the program could be invoked
simultaneously. It worked only so long as there was only one message at a
time, a rate so slow as to not require rate limiting.

But abusers do look and behave differently from regular users.  This can
be exploited to some extent.  Slow queues that wait for an abuse pattern,
and so forth.  But the best thing is to just block the blacklists from 
scanning. And the techniques I just described to Tony Finch.

> The problem is with zombies.  They make mush of old-time models of spam, since
> they demonstrate that a very small data stream from a single source can be
> leveraged into a very, very large data stream, given enough sources.

It is interesting that the most recent "email authentication" scheme (SPF)
asists the zombies by identifying the ISP's (possibly closed) outgoing
relays. If the ISP happens to block port 25, which may be attractive to
residential ISPs which also happen to have the most zombies, then the
zombie needs to use the ISPs relays.  Finding that relay for a thousand
different mail clients is a chore, and would have to be performed by a
severely limited virus payload. But along comes SPF, and identifies those
relays for the zombie.  Foot, gun, trigger. Or perhaps SPF was more
intentional, and also happened to be a great source of money.

> I don't know how much experience you have trying to do such tracing, but the
> spamops folks have made quite clear that it is both vastly more effort and
> considerably less productive, than one might expect.  Again, there is no way
> that relying on that is a reasonable best practise on the current Internet.  As
> a small example, not that spammers now are stealing IP Address blocks.  That
> pretty much kills backtrace accountability.

The spamops folks are frequently unreasonable in this respect. They have
asserted, for example, that one cannot trust _any_ mail headers.  They
expect _immediate_ results. Those are just unreasonable demands.  No ISP
is going to cancel a users account on the say-so of some unreasonable
anti-spammer, who (as a group) are already well-known for outright lying,
revenge, and defamation.

Tracking a spam zombie requires a bit of patience and persistence. There
is nothing that will make that easier, except perhaps a standard abuse
submission protocol (which I proposed back in 1999).

> >  unfortunately, the vigilante character of various open-relay blacklists
> 
> blacklists are not the subject of this BCP.

Its couched in terms to avoid that, and just assumes the blacklists claims
about open relays are right.

> >  killed any attempt at this kind of innovation.  just as we're now in
> >  danger of various kinds of brain-dead "authentication" methods and
> >  meaningless requirements killing useful email functionality.
> 
> new authentication methods are not the subject of this BCP.

It doesn't specify a specific method. It just says that email
authetication should be used.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]