> Maybe a problem can occur if a customer sends out a large number of
> e-mails and there are several bounces. But if this happens I assume
> that the addresses was not aquired "regulary" ;-)
I wouldn't say that's an accurate assumption; site-specific factors
will dictate what % of bounce traffic is commonplace. We have several
clients that receive hundreds of bounces from 10,000+ mail blasts
every month, others who only receive legitimate bounces from
person-to-person correspondence and so would be more appropriate for
the flood detection concept.
Yet this whole concept of NDRs from Joe Jobs tipping the balance of a
server's operability sounds really fishy to me. We have servers
passing hundreds of thousands of messages per day, with only
negligible examples of such traffic actually being submitted for
delivery. One difference? We reject unknown addresses at the envelope,
continuing to follow best practices while preserving our users' right
to their legitimate rejections as much as we all want to preserve our
users' right to their legitimate messages. That's just one difference
between our setups and others, but I'd like to harp on that one for a
bit.
Joe Jobbers want to use as legitimate a return path as possible. If
they use a real address at a real domain, messages will pass sender
address verification (SAV) at the recipient, giving them a major leg
up. In the old days, using a fake address at a real domain was
workable, but SAV has upped the ante, making a real (i.e. validated)
address preferable. At the same time, they're aware that using the
return path of a not just validated, but user-attended mailbox can
only be done for a brief period of time, since attended mailboxes
being flooded with bounces will inflame their attendees and in turn
their attendees' providers (and the legal issues governing
impersonation are more clear). What's their dream? Knowing that a
domain accepts mail to any permutation you throw at it, regardless of
whether the mailboxes actually exist. And preferably a smallish domain
that won't track them down. This is the equivalent of a /dev/null drop
for their bounces--provided they use rotating return paths at that
domain, they can minimize the detectability of their Joe Jobs.
And their accomplice in those habits? Ta-da: the 'nobody' alias. And
that's just one of the many problems with enabling 'nobody' on an
IMail server.
...not only does 'nobody' aid spammers in getting through to their
targets. When accompanied by second-level bounces, it makes your
domain complicit in the generation of Joe Job bounce traffic (see the
% of Joe Job bounces from AOL that could be avoided if they enforced
envelope rejection of unknown senders). Or, if unaccompanied by
automated bounces, it makes you jump through ridiculous hoops to
provide customer service to legit remote and local users who deserve
to know their mail has bounced. Since the only way to responsibly
(vis-a-vis the humans who use your systems) use 'nobody' on a mailbox
server is to hand-examine messages that are not otherwise caught by
your anti-spam measures, and cursory examination is not sufficient to
determine legitimacy in all cases, you must either spend a ton of time
grepping your logs or generate bounces manually, both of which methods
add totally unnecessary delays--even when your mail volume is small
enough to make them work.
...and not only does 'nobody' unnecessarily complicate administrative
tasks. It also increases your own chances of being suspected as the
origin of spam. While the distinction between envelope sender and
source IP is clear to experienced mail admins and anti-spam
blacklists, it's not clear to everyday users and part-time admins.
...and not only does 'nobody' aid spammers directly and expose your
domain needlessly, it also aids them indirectly by helping to make SAV
impossible to trust positively. I'm well aware that it's not just
IMail shops that accept all messages at the MX; there are indeed huge
providers that do the same thing (despite some *real* hardliners,
harder even than me on this topic, who attempt to frame this to the
contrary). But the huge providers have good reason, as they're
performing other checks at the envelope and fielding thousands of
messages per second, and address lookup is costly when your user count
is truly gigantic; and at least they generate bounces automatically,
rather than forcing hand-inspection. So I'll let them off the hook for
now. But the story is different for well-put-together IMail MX/mailbox
servers, which have no such excuse and whose admins should be trying
to avoid gorilla-like tactics. Why not cooperate with SAV and enable
others to 55x [EMAIL PROTECTED] Joe Jobs, instead of deliberately breaking it?
...and not only does 'nobody' aid spammers directly and indirectly and
expose your domain needlessly, it also forces you to spool messages
that will never, could never be delivered to humans. 'Nobody' aliases
receive spam. This is a matter of fact. CD-ROMs are sold with more
aggregate mailboxes than could possibly be attended by the population
of the planet. Like most of our spam, it's likely to be flagged by
tests and filters and end up over the HOLD weight. But ask your disk
subsystem if that's painless. This, to me, is the most crucial issue:
the use of local resources. Sure, maybe you don't care about the
effect on remote servers or on the Net as a whole. But is your server
happier taking out the trash, or making the sender take it out?
...and not only does 'nobody' drain server resources for accounts that
have never existed, it forces the acceptance of messages for accounts
that have been terminated. This upends the very concept of user
pruning. Hosting a ton of loss-leader webmail accounts with an
accompanying high turnover rate, and still using 'nobody'? Or spend a
few hours of your week doing adds/deletes/changes on a corporate
userbase? That giant sucking sound you hear is the sound of your drive
accepting mail for users who have, in many different ways, left the
building.
...and not only does 'nobody' tax your server with the unnecessary
acceptance of mail, the user lookup itself does not conserve any
resources compared with lookup against a userbase without 'nobody.'
IMail will seek the user in either case, then fall back to the
'nobody' target, so you're not conserving ODBC traffic, local Registry
access, or any such resource.
...and, finally, 'nobody' aliases have never been shown to offer
substantive protection of server resources by discouraging
dictionary-based harvesting. The breadth of dictionary attacks on
particular domains has much more to do with their publicly known user
counts than on the results of such attacks. It is true, though, that
they can hit servers of any size. Yet the thinking that 'nobody' is
preventing your sure shutdown or slowdown by dictionary attacks is at
odds with the fact that spammers' unlimited bandwidth is distributed
and controlled, and sending shots of as little as 30 RCPTs at a time
over a period of months is not uncommon, with many, many rotating
source IPs. Thinking that you're wasting the spammer's time is absurd,
when the machines that are probing you may never see a human operator.
Consider the once-universally-celebrated 'connection tarpitting,'
which was defeated by the same logic (they've got bandwidth to waste,
you don't). By spammers' own design, attacks aren't what they used to
be, when attempts streamed in from the same IP for long enough to
blackhole that IP or trash the server. Further, for a small domain,
the pace of addresses being successfully dictionary-harvested is much
slower than (a) the pace of new filter-avoidance techniques and (b)
the addresses gathered through other means. Again, a question of
priority: the attacks one thinks they're avoiding, as a lucky result
for admins, likely wouldn't have used enough resources to actually
threaten the stability of the server, the negative technical
consequences are non-negligible, and the time you waste distracts you
from a better fight. With dictionary attacks, having procedures in
place to trace and block the source IPs at the border, figure out an
attack threshold, detect spamtrap recipients, and so on, is a better
use of everybody's time. Concluding that not seeing prolonged attacks
on a few servers that have 'nobody' enabled means that 'nobody' is
essential to servers' survival is not only unscientific but at odds
with the experience-based practices of a commanding majority of
systems administrators and architects--in not only the distant past of
early SMTP, but all the way through the current state of the protocol
(see P.S. for an additional comment.)
In sum, 'nobody' has a net negative effect on your resources and a net
negative effect on the rest of the Net. As a great man has said,
"Since when is knowing an e-mail address sufficient to get spam
delivered?" :)
So why have I harped on 'nobody' when the original topic was Joe Job
bounces? Because what links them in the anti-spam fight is the waste
of resources they cause *above and beyond* the resources used by spam
messages to and from real people, both on servers you control and
servers you don't. If you're complaining, even in part, about bounces
to users that your server knows to be nonexistent ("known unknowns,"
to quote a famously frightening individual), don't accept the mail.
Complaining about those messages is like complaining that the post
office keeps delivering junkmail to your next-door neighbor, whose
mailbox you just can't keep yourself from opening (sort of).
Of course, that still leaves you to deal with the Joe Jobs against
humans (user-attended mailboxes). But while managing *these* Joe Job
bounces is a worthy idea, it means tilting at the windmills of
hundreds of different bounce formats and explanations. And the bounce
volume you see from JJs should be a fraction of the volume you see of
spam itself, so the relative rewards will be fewer and the risks much
greater. If the bounces are indeed overpowering to a single accounts,
the user's probably the target of someone's revenge through a
deliberate DoS. In that case, what would be useful is the ability for
*the user* to turn off all bounces--with a radio button *completely*
under their control at all times--for a period of time, with full
documentation of why, when, and the consequences; never mind trying to
select out what's a permanent bounce, a transient bounce, whatever
during this period. This would be trivial to code within an IMail web
page, and I will be adding it to our custom pages, in all likelihood.
All the same, dropping everything during such an attack without a
second look is unwise, as there may be legal remedies and will almost
certainly be filter-based remedies as well (search for IP source
[xx.xx.xx.xx] in the message body).
On still another hand, embracing and propagating anti-forgery
technologies like SPF allows you to take the offensive, and while
sender address forging is not spammers' only tactic, there's no reason
to throw in the towel and decide that all you can do is go on the
defensive, since SPF is doomed to failure. The only people who can
doom it to failure are those that won't take the tiny steps to adopt
it--or whatever anti-forgery tactic gains consensus--preferring to
tackle secondary obstacles instead. If you fight forgery itself, the
resultant bounces are also fought, doubling the effects of your work.
--Sandy
P.S. I'll make a case-study argument while I'm on the topic. So get
yourself into Microsoft-skeptic mode, if applicable. Good. Now realize
that until Exchange TWO-THOUSAND-THREE, MS did not reject unknown
users at the envelope. Now they do. So: did they know something other
mail server vendors didn't know for the past decade, then suddenly
forgot it this year? Did they bow to some backward-thinking bully like
me and reverse a long trend of innovation? Think about it.
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
