[LINK] RFI: Email Download Failure from Local ISP

[Craig Sanders]

On Tue, Jan 22, 2008 at 11:29:35PM +1100, Scott Howard wrote:
> On 1/22/08, Roger Clarke <Roger.Clarke at xamax.com.au> wrote:
> >
> > At 22:00+11 Tue 22 Jan 2008 and up to 23:00ish, fetches of mail from
> > mail.apex.net.au were dropping out - Eudora said 'No response after
> > 120 seconds'.
> >
> > The Squirrelmail/webmail alternative also wasn't working, just
> > hanging, and finally displaying a message I haven't seen before (at
> > the very bottom).
>
> Sounds like either the POP server is broken, or you're got a massively
> large mailbox which is taking too long for the server to open.  The
> former is more likely...

yeah, that would be my guess too. apex's mail server is/was likely
down. such things happen from time to time, even for giant ISPs that
can afford to throw lots of money, staff, and hardware at mail server
infrastructure.

> So their own mail servers are the primaries, and Telstra is a backup
> (lowest numbers are highest priority, the order they are listed in
> above isn't relevant)

something like this was recommended practice 15+ years ago, but it's
considered bad practice these days to use a backup MX that you do not
control, and that does not have the same anti-spam/anti-virus setup as
you do.

spammers & viruses target backup MX servers(*), and have done for years.
there are two immediate consequences of this:

1. it can be a way to bypass some of your anti-spam/anti-virus rules
(especially those that check the sending client's IP address) or even
all of them if you configure your mail server to blindly trust your
backup MX....and if you're misguided enough to use a backup MX you don't
control, it's quite possible that you're misguided enough to do that.

this is, of course, the reason why malware deliberately targets backup
MX servers.

2. backscatter. it's uncommon for backup MX servers that you don't
control to know which email addresses are valid for your domain, so they
typically accept all mail addressed to any user @yourdomain. when the
backup MX tries to deliver mail for bogusaddress at yourdomain, your mail
server will reject it and say "no such user", and the backup then has
to bounce the message. leading to what is known as "backscatter", or
bouncing mail to forged sender addresses.

note that there is a huge difference between rejecting a message (as
your mail server can do because it knows what the valid addresses are),
and bouncing a message (which involves first accepting a message and
then sending it back to the alleged sender).

most spamware/viruses will just drop the message if it it rejected,
because there's no need to program in bounce-handling code or waste
bandwidth delivering a bounce rather than another spam, so a rejection
won't result in backscatter like a bounce will (unless there is some
real mail server as an intermediary, such as a backup MX that you don't
control).


(*) that's why i have a dummy secondary MX record for my domain, and
my firewall drops all SMTP packets except to/from my mail server. it
doesn't actually achieve much but waste the time of spamware trying to
connect to it, hopefully slowing it down. and doing it did show that
some spamware targets backup MXs exclusively - the amount of rejected
spam in my mail logs went down noticably after i set that up a few years
ago.



BTW, apex's secondary MX setup won't affect mail sent to your domain.
your domain's MX records list only apex's mail servers.

$ host -t mx xamax.com.au
xamax.com.au        	MX	0 mail.apex.net.au
xamax.com.au        	MX	20 mail2.apex.net.au


> > DNS-server is on the same subnet as the primary, in breach of the
> > (advisory only) IETF RFC, i.e. the nearest thing to a standard that
> > exists in Internet contexts]
>
> Given that their entire ISP is probably on that same subnet, it
> probably doesn't make a lot of difference.  There are a hell of a lot
> of "advisory" RFCs out there - many of which were far more relevant
> in a 1990's Internet rather than a 2008 Internet (Not to mention that
> many of them contract either themselves, other advisory RFCs, or in
> many cases contract the standards track RFCs...)

yep.  i wouldn't consider it reason enough by itself to leave an ISP,
but it is a bad sign.

apex should find another similarly sized ISP (perhaps via the aussie-isp
list that i run) and make a deal to provide secondary NS facilities for
each other.  the catch is that you've got to pick one that is unlikely
to go bust because it can be a major PITA to have to suddenly redelegate
your domain(s) because one of your nameservers has vanished off the net.

or just pay for a secondary NS, there are services around that do it for
a fee, and it's dirt cheap to pay for a virtual host on a server in a
well-connected spot in the US - bandwidth requirements would be minimal
for just serving DNS requests.  actually such a machine could act as a
backup MX too.

craig

-- 
craig sanders <cas at taz.net.au>

Religion is what keeps the poor from murdering the rich.
		-- Napoleon