So your auditor wouldn't mind if you kept an unencrypted list of credit card
numbers on a DMZ box, because if somebody hacks the box they can gather those
over time? 
This is hardly the same thing. E-mail addresses are public, credit card numbers aren't. Email addresses can be gotten by brute-force checking fairly easily without even cracking the machine. card numbers can't.
What would your auditor think about your secondary MX being used as a DOS amplifier because it sends out thousands of bogus bounces to forged addresses ?
You're missing the main point - that sometimes things are done in ways that are
sub-optimal or even pessimal from the technical standpoint, because some other
consideration interferes. Yes, it *would* be nice if everybody in the world
was able to DTRT on their outward-facing gateway and send back an immediate 550
on a RCPT TO: in order to stop stuff right up front. However, this implies
getting buy-in and resources of all the appropriate people.
I'm sure *everybody* has had at least one Good Idea either totally shot down or
mutated beyond recognition because it wouldn't pass auditors (either internal
or external), or because it involved purchasing from Company X because X is the
only one with the feature support, but you'll never get that purchase order
approved by the "it must be Company Y gear" manager, or because deploying it
would involve getting buy-in from somebody in applications development, and
they don't understand why the urgency on this new feature you need them to
add...
: Yes, it *would* be nice if everybody in the world was able to DTRT on
: their outward-facing gateway and send back an immediate 550 on a RCPT TO:
: in order to stop stuff right up front. However, this implies getting
: buy-in and resources of all the appropriate people.
Blocking outbound mail from such entities is a pretty good way to get
buy-in. (Yes, there's a DNSBL in work to enumerate such systems.)
Oh, I know that point very well. It's why we're in the mess we are in, because no one could budget to set things up properly.
It's the same arguement we heard as to why people couldn't close their open relays. To which we eventually responded "OK, if that's what you have to do. Let us know when you have fixed it and we'll accept mail from you again. You'll have to use a different server though, 'cause it's blocked now".
It's not that I missed the point. I don't care if YOU can't afford it. That's your problem. I'm not going to let it affect MY network.
You're missing the main point - that sometimes things are done in ways that are sub-optimal or even pessimal from the technical standpoint, because some other consideration interferes. Yes, it *would* be nice if everybody in the world
But if you really need a reason to convince someone who won't get their head out of their . . . the sand -- You can probably cut in half the number of viruses you have to scan if you reject invalid addresses up front, meaning you can buy a smaller/ fewer virus scanner(s).
Which means the companies making them have absolutely no incentive to add this feature.
When it gets built, will it list AOL.COM for not rejecting at the original RCPT
TO? Or Hotmail.com? (Consider the following 2 pieces of mail - mail comes in
from someplace with a From: @aol.com, our Listserv tries to process the command
(which was actually spam, but it's hard to tell that until you try to handle
it), and send the response back... notice that AOL didn't 550 my mail, but
accepted and bounced it. Similarly for the hotmail.com mail - the spam comes
in, and they accept-and-bounce our response rather than 550 it (although to be fair, they
usually DO manage to 550 this stuff).
Yes, it's generally a good idea - but not one that everybody can carry out all the time.
You don't like it, take it up with the AOL and Hotmail guys, not me, OK?
Don't know about hotmail, but AOL is working on this. You might want to check out that SPAM-L list, if this is something you are interested in.
Once AOL starts doing it -- you can bet they will be one of the ones blocking on it.
Right. Mirapoints are that way too (at least in our configuration). And yes,
we'll probably have to buy a 5th Mirapoint and/or upgrade our current 4 sooner
because of it - but the incremental cost for that is *still* lower than the
cost of replacing them with another vendor's gear....
Now how do you explain to the CFO that in order to get around a $50K upgrade
to the current gear, you want to spend $200K to bring in another vendor?
Don't know about hotmail, but AOL is working on this. You might want to
check out that SPAM-L list, if this is something you are interested in.
Other than knowing that it's a good idea if you can do it, but sometimes not
doable with the resources at hand, I don't have any special interest in it...
Once AOL starts doing it -- you can bet they will be one of the ones
blocking on it.
That's going to pretty much torpedo the concept of secondary MX's.
: > Blocking outbound mail from such entities is a pretty good way to get
: > buy-in. (Yes, there's a DNSBL in work to enumerate such systems.)
:
: When it gets built, will it list AOL.COM for not rejecting at the original
: RCPT TO?
AOL happens to be working with the anti-spam community by converting their
MXs to do reject-at-SMTP. (See SPAM-L archives. They're quite aware of the
problem and are in fact addressing it.)
: Or Hotmail.com?
Strange; I've received direct SMTP rejections from Hotmail plenty of times
recently. Given the size of that entity, I'm sure the DNSBL admin in
question would try to work with them (and Hotmail admins have also shown
themselves on SPAM-L); but without any movement, yes, it'd be a candidate
for listing.
(was: Re: Barracuda Networks Spam Firewall)
: > Don't know about hotmail, but AOL is working on this. You might want to
: > check out that SPAM-L list, if this is something you are interested in.
:
: Other than knowing that it's a good idea
s/a good idea/an emerging requirement/
(and for one definition of the idea, s/a good idea/a soon-to-be RFC "MUST"/)
: if you can do it,
s/can do it/wish to send mail, or at least DSNs, to most of the 'net soon/
: but sometimes not doable with the resources at hand,
s/.*//
Those of us under a deluge of virus bounce spew just don't care anymore.
If you don't reject at SMTP time, you're now a major part of the problem.
(As a straw example, I happen to block, on a personal 12 user domain, almost
20k bounce spew attempts per day. That's simply untenable anymore.)
: > Once AOL starts doing it -- you can bet they will be one of the ones
: > blocking on it.
:
: That's going to pretty much torpedo the concept of secondary MX's.
And what's the gain of secondary MX's that don't have access to a valid
address list? Ever since the advent of globally deployed, permanently
connected sending MX's, offsite secondary MX machines have become moot.
SMTP mandates that a missed connection is equivalent to a 4xx error, in that
the sender is to retry delivery later. That obviates any need for an
offsite secondary MX in today's world.
Unauditable SMTP transport -- that is, SMTP where neither the sender nor
recipient values are verifiable -- is no longer a workable solution. The
problems with that model are reaching critical mass, and if you don't think
it's a problem now, just trust me; you'll be a believer soon enough.
Folks still run those? No really, most people I know terminated their
off-site secondaries a couple of years ago at least.
The only secondary you can reasonably use these days has (1) a copy of
your user list, and (2) a clone of your spam filters.
Much as I hate to come to their defence, hotmail rejects unknown users
during the dialog, and has done so for as long as I can remember.
That may be so. But I've got 208 hotmail.com hosts "back"listed for
backscatter dreck such as this:
--8<----8<----8<--
From MAILER-DAEMON Wed Apr 14 16:17:33 2004
Received: from mc6-s2.hotmail.com (mc6-s2.bay6.hotmail.com [65.54.251.76])
by serrano.hesketh.net (8.12.9p1/8.12.8/NO-UCE-NO-UBE-NO-spam) with ESMTP id i3EKHVAh005383
for <rbghvavo@munged.com>; Wed, 14 Apr 2004 16:17:32 -0400
Received: from mc6-f11.hotmail.com ([65.54.252.147]) by mc6-s2.hotmail.com with Microsoft SMTPSVC(5.0.2195.6713);
Wed, 14 Apr 2004 13:17:36 -0700
OK Steve let me know when you have the sendmail ruleset to check quota on a remote host before accepting RCPT To:
Not the point. Point is that mail sent to a hotmail.com address from a
forged sender was accepted, was not delivered, and the DSN sent to the
forged sender.
It's not really my business why a hotmail.com MX accepted mail it
couldn't deliver. I could care less /why/. It's up to hotmail to fix
their systems - I don't care how they perform that background check on
quota.
It's my business that over the past sixty days, we've had to reject over
23K of these, and had rejected some 130K in three weeks during March, at
the peak of the joe job. At one point, backscatter accounted for 70% of
my inbound email traffic on one host. Almost made the usual spam and
virus look like background noise.
Not to suddenly burst back, but ...
Second/terti/etc-ary MXers really belong in a bygone age anyway.
There was a time when IP was a novelty, and UUCP was king. Then there
was a time when UUCP was getting long in the tooth, but politics
dictated an IP Internet that was not universally connected. Somewhere
in the meantime, leading a life of its own, was something called
FidoNet (http://www.fidonet.org) and something else called BITNET
(http://www.bitnet.org), but as of today both are for pub brawls only.
This is of course an opportune moment to recall that the 10th anniversary
of the shutdown of the successor of mcvax.bitnet, namely mcsun.bitnet,
was in January of this year. http://www.mcvax.org/mcsun/
The fundamental idea of less preferred MXs was to get the mail delivered
through a backdoor, not reachable via IP routing from the originator.
Think multihoming for email, keeping in mind that email routing is
disjoint from IP routing: a genuine secondary MX would be able to,
one way or another, deliver the mail, by means not accessible to the
originator. This inaccessibility would be because the more preferred
MX was unreachable for one of several reasons (host down, network down,
or politics enabled), but, whatever the reason, one wanted to find a
way of routing around the problem.
For a long time since then, backup MXs have been seen as a kind of
value-added courtesy service; they serve no really useful purpose,
but look good on a checklist. In practice, of course, in the current
Internet it rarely matters on which host an undelivered email is spinning
in the spool area.
Best,
  -- Per
well, they're handy for centralizing filters against multiple domains, if
you're willing to put your various primaries at the mercy of the filter
service, and if the filter knows your valid recipients. what with
ldap-smart servers and fancy routing, this isn't even hard anymore.
but general "backup" MX is long-time dead. first the spammers killed our
outbound flexibility by forcing everybody to close their relays, and then
they killed our inbound flexibility by forcing everybody to close their
generic backup MX paths. that cracking sound is stress fractures as the
network gets more rigid.
But this only means that the primary, and only, MX should be the
filter service MX; in turn, it would deliver sanitized email to
its real destination.
An amusing twist on this is then that the final recipients could
be listed as less preferred MXs -- if the filter service MX is down,
one would accept all mail unfiltered, rather than wait until the
primary, filter service, MX is back on line.
While this would be a legitimate use of less preferred MXs, even if it
practically turns the original rationale upside down, I would generally
suggest to opt for uncompromising reliablity on a filter service MX,
and fall back on DNS changes for disaster recovery, rather than receive
tons of junk unfiltered mail whenever there's a glitch on the primary,
filter server, MX.
But your point is technically correct. Only goes to show how much
mileage there is to be had from an otherwise very simple protocol
extension.-)
Best,
  -- Per