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

Spamhaus...



On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
> Whine all you want about backscatter but until you propose a
> comprehensive solution that's still reasonably compatible with RFC
> 2821's section 3.7 you're just talking trash.

We're well past that.  Every minimally-competent postmaster on this
planet knows that clause became operationally obsolete years ago [1], and
has configured their mail systems to always reject, never bounce. [2]

For the rest, that are still sending backscatter/outscatter spam on 
a chronic/systemic basis, we have spammer blacklists, since
of course they *are* spamming.

It should be obvious on inspection to everyone that one of the very
last things we should be doing when we are drowning in useless/junk
SMTP traffic is to generate more of it.

Doubly so when, as we have seen, abusers have demonstrated the ability
to repurpose it as a formidable weapon.

---Rsk

[1] Thanks in part to the rise of the zombies, to the ready availability
of cheap/free domains in bulk, to anonyous/obfuscated registration, to
fast-flux DNS, and to a number of other factors.  And no, SPF does not
in any way mitigate this problem.  Neither does DKIM.  Neither does
SenderID.  Neither does *anything* except not sending it.

[2] Yes, there are occasionally some edge cases of limited scope and
duration that can be tough to handle.  However, well-known methods exist
for minimizing these in various mail environments (e.g., front-end/back-end,
multiple MX, etc.), and these have been elucidated and discussed at length
on the relevant mailing lists, such as spam-l.  The key points here
are "limited scope" and "limited duration".  There is never any reason
or need in any mail environment to permit these problems to grow beyond
those boundaries.