----- The following addresses had permanent fatal errors -----
<abuse@cox.net>
(reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.)
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
Seems to be perfectly wise if you're a business and care more about making
money than getting all tangled up in pesky things like morals and ethics. It's
great when you can help the balance sheet by converting "ongoing support costs"
and "loss of paying customers" into what economists call "externalities" (in
other words, they make the decisions, but somebody else gets to actually pay
for the choices made).
This is one of the threads where posting further will not be productive.
Cox abuse has been named and shamed, and hopefully, the next post we see
to the thread will be from them.
As a reminder, political discussions, and discussions about spam filtering
(other than operational, such as abuse@ or noc@emails) are off-topic for
nanog. Please keep it this way.
----- The following addresses had permanent fatal errors -----
<abuse@cox.net>
(reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.)
This seems a rather unwise policy on behalf of cox.net -- their customers
can originate scam emails, but cox.net abuse desk apparently does not care
to hear about it.
I haven't had any issues between my network and cox related to mail
operations lately.
Heh better then my all time favorite was the "mailbox is full" reply
from an abuse@ address for an ISP based in Nigeria who had a few servers
trying to open umpteen fraud accounts
I've seen my share of 800-pound gorillas (we're talking the 10M+ customer
range) who have bounced postmaster@ and/or abuse@ due to 'mailbox is full'. So
it isn't just small ISPs in little corners of the world...
My favorite was an abuse@ bounce from a smaller shop that read something like:
451 <abuse@smallshop.com> Mailbox Full of complaints, even though we nuked their butts 3 days ago.
(I'm sure many readers of the list know *that* feeling - you found and fixed
the problem before the first complaint arrives, but you still get deluged by
more complaints for another week or so...)
An unfortunate limitation of the SMTP protocol is it initially only
looks at the right-hand side of an address when connecting to a
server to send e-mail, and not the left-hand side. This means abuse@example.com first passes through the same server as all of
the rest of *@example.com e-mail. A single high-volume or special
address can easily overwhelm the normal email infrastructure (i.e. mailbox full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).
Even the FTC's UCE uce@ftc.gov e-mailbox has had problems, which affected the rest of *@ftc.gov e-mail. So the FTC created a separate right-hand side name spam@uce.gov to separate UCE reports from normal
FTC e-mail channels which lets them route the mail with separate mail handling policies based on the right-hand side.
(I'm sure many readers of the list know *that* feeling - you found and fixed
the problem before the first complaint arrives, but you still get deluged by
more complaints for another week or so...)
I guess you're saying there's something architectural in email that makes it impossible/difficult (limitation) to apply different policy to the LHS.
That's not correct though. The receiving MTA is quite free to apply differing policies to different LHSes. And at least one MTA allows you special-case measures applied to tables of addresses, such as whether DNSbl lookups should be applied.
SMTP is distributed, so you do of course have to take care to keep distributed policy consistent. But, again, that has nowt to do with LHS/RHS of email addresses.
is going to go to whatever MX example.com returns.
Sean's point was that you can't cause, e.g., eg@example.com alone to
go to a server other than the same set of servers listed for AnythingElse@example.com.
If that (eg@example.com) overloads those servers, even if they're
valiantly trying to pass the connection off to another machine, then
you have to use some other method like eg@special.example.com or eg@other-domain.com and hope the clients will somehow use that tho for
BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM.
It can be a problem in joe jobs, as one e.g.
If you think I'm wrong (or Sean's wrong) even for a milisecond then
trust me, this is going right over your head. Think again or email me
privately and I'll try to be more clear.
P.S. It's an interesting thought. The only approach to a solution I
could imagine is that the whole address would have to be passed in the
MX query.
If that (eg@example.com) overloads those servers, even if they're
valiantly trying to pass the connection off to another machine, then
you have to use some other method like eg@special.example.com or
eg@other-domain.com and hope the clients will somehow use that tho for
BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM.
... and the RFC says that, and those people that still do manually
report abuse will email abuse@domain or postmaster@domain instead of
hitting report spam and letting their ISP forward it across in a
feedback loop (which will go to an entirely different, machine parsed
address as the ARF spec is designed to let you do).
You can always alias abuse@ internally to a subdomain if you wish -
but that wouldnt be because abuse@ slows down your MXs. The smtp load
inbound to an abuse mailbox will be fairly small compared to the
general load of smtp (and spam) coming your users' way for sure.
There's lots of ways to manage an abuse mailbox (such as filter spam
to your abuse mailbox into a bulk folder, review it and then feed it
to scripts that parse the spam and feed the results to your filters).
MAAWG's been working on an abuse desk bcp for quite some time (the
hard / tech part of it, as well as soft abuse stuff like motivating
and training abuse deskers, giving them career paths etc)
Yes of course - but only a fundamental problem where the MX servers are
hopelessly overloaded.
This is different from the situation described in the original post, where
filtering policy is being applied indiscriminately regardless of recipient
LHS, which is generally a sign of substandard software or foolish admin.
As others have said, normal practice is to apply different filtering
policy to certain LHS values (abuse@) and to provision enough MX capacity
such that the service as a whole is functional (including receiving abuse
reports).
P.S. It's an interesting thought. The only approach to a solution I
could imagine is that the whole address would have to be passed in the
MX query.
Once upon a time (1987) there was this experimental facility called MB
(mailbox) records which did exactly that. Unfortunately, they never
caught on in any real way, and the only historical mark that they seem
to have left is the rather odd way in which we express the RNAME
(mailbox of the responsible party) in an SOA record.
Maybe it's an idea whose time has come again. How many years would it
take to have a meaningful rollout if we start now? 10? 20? OK,
nevermind then.
P.S. It's an interesting thought. The only approach to a solution I
could imagine is that the whole address would have to be passed in the
MX query.
Once upon a time (1987) there was this experimental facility called MB
(mailbox) records which did exactly that. Unfortunately, they never
caught on in any real way, and the only historical mark that they seem
to have left is the rather odd way in which we express the RNAME
(mailbox of the responsible party) in an SOA record.
Maybe it's an idea whose time has come again. How many years would it
take to have a meaningful rollout if we start now? 10? 20? OK,
nevermind then.
---Rob
Yeah 'cus by then there will be no address space left, all the routers would have blown up with too many prefixes, sea levels would have risen by 100 M and half the world will be under water. Not to mention the fallout from the middle east nuclear exchange, the bird flu epidemic, the asteroid hit and that the oil shortage means that China can no longer make any cheap plastic tat. If there is no cheap plastic tat, then Internet commerce will die because there will be nothing to buy!
Great. So half the world's population is dead, lots of dotbombs are
out of business .. but you have LOTS of IP space that's suddenly
unused and available.
is going to go to whatever MX example.com returns.
Yes, I'm aware.
Sean's point was that you can't cause, e.g., eg@example.com alone to go to a server other than the same set of servers listed for AnythingElse@example.com.
Right, his point was that load or policy (" administrators may make changes which affect all addresses) would cause a problem, and this was, for some reason, due to routing of email addresses.
I took issue with the policy side of the comment. While it's possible, it's got nowt to do with limitations in SMTP routing, it's just operator error.
If that (eg@example.com) overloads those servers, even if they're
valiantly trying to pass the connection off to another machine, then
you have to use some other method like eg@special.example.com or
eg@other-domain.com and hope the clients will somehow use that tho for
BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM.
Right, I do understand that. There are obvious ways to horizontally scale inbound mail using MX records and more, so the load issue shouldn't be an issue for any given organisation. Least not more than once.
However, I didn't comment on the load part of Sean's point.
If you think I'm wrong (or Sean's wrong) even for a milisecond then
trust me, this is going right over your head. Think again or email me
privately and I'll try to be more clear.
