North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: AOL scomp

  • From: Rich Kulawiec
  • Date: Sat Feb 26 14:43:05 2005

On Fri, Feb 25, 2005 at 01:34:21AM -0600, Robert Bonomi wrote:
> Because the recipient *expressly* requested that "all mail which would reach
> my inbox on your system be sent to me at AOL (or any other "somewhere else").

I have three somewhat-overlapping responses to that -- and I'll try to
stay focused on operational issues, since this is NANOG, not Spam-L.
(But if you to delve further into this, I would suggest shifting the
discussion there, as it's probably more appropriate.)

1. SMTP spam is not mail.

Oh, it may *look* like mail, it may arrive on the same port, and it
may use the same protocol, but it's not mail.  It's abuse.  There's no
reason to forward it to anybody.  There's no reason to even accept it
in the first place.

Heck, there's no reason to even _emit_ it in the first place.

Which (not emitting it) is what everyone should be trying to do, but
few are.  It seems to have somehow escaped the notice of many that
spam/abuse doesn't fall out of the sky: it comes from systems.  Those
systems are on networks.  Those networks are run by people.  Those people
are personally responsible for the spam/abuse that their networks emit.
It's thus their responsibility to make it stop.  But their failure to
properly discharge that responsibility is why we have a major problem,
or actually, several major problems, instead of a minor annoyance.

[ Let's have a moment of nostalgia for the time when allowing this
to happen day after day would not happened because the plug would
have been unceremoniously pulled after the first 24 hours.  It's
illuminating how quickly "unsolvable" problems are at least patched
to an acceptable degree when connectivity is at stake. ]

2. Mail delivery requires permission of all of:

	- the network operator
	- the system operator
	- the mail subsystem operator
	- the end user

(who of course are sometimes all the same person/people).  For instance,
the end user may grant permission for someone to send 500M video clips
attached to mail messages, but if the mail subsystem operator has
limited mail message sizes to 10M, then permission is denied and the
mail message is turned away.  As another example, if the end user has
granted permission for 5000 messages/second, but the network operator
has capped bandwidth at a level below that required to transmit those
messages, permission will be denied.

What I'm trying to say is that merely having the permission of the end
user to send something isn't enough: one also has to have permission
from the authorities involved in providing the service, and their
permission may be conditional on certain requirements enforced
by automated agents, e.g., "you will only be given permission if your
message is <= 10M" or "you will only be given permission if your message
does not contain a live virus".

Or "you will only be given permission if your message isn't spam", or 
"you will only be given permission if your message isn't coming from
a domain/system/network known to emit prodigious quantities of spam".

I see no reason for any of those four people to grant permission to
receive or forward spam *except* for those very few conducting research
in the area (similarly for viruses), and those people aren't going
to want it via a forwarder anyway.

So while the end user on some remote system may have in fact said
"send me everything, including the spam" (although this seems very
unlikely) this does not constitute permission to do so, because that
user isn't the only party involved, and their permission alone is
insufficient.  (logical AND required, not logical OR)  And I doubt very
much that the others will give their consent.

3. Dealing properly with forwarded spam which is rejected by the destination
is tough: generating bounces will make the generator a spammer-by-proxy,
and that's obviously unacceptable.  A much better course of action
is to try to reject as much spam as possible -- rather than accepting it,
trying to forward it, and then bouncing it (thereby spamming innocent
third parties, and self-nominating for inclusion in various blacklists).

Bottom line: deliberately forwarding spam makes you a spammer.  Don't do it.
If a user, for some bizarre reason, insists: don't do it.  Tell them 
to find an irresponsible, spam-supporting ISP to do it for them -- there
are certainly plenty of those around to choose from.

> This means that every such message from the 'forwarding' system to the
> destination system is, BY DEFINITON, "solicited". The mailbox owner has
> expressly and explicictly requested those messages be sent to him at the
> receiving system.

This is a definition of "solicited" which is wholly at odds with that
in common practice for the last few decades.   By your definition,
the victim of a mailbombing attack would have somehow "solicited" that
abuse merely because they have a forwarding alias on your system.

I'm not having any.  UBE (the proper definition of SMTP spam) doesn't
magically become not-UBE just because it gets forwarded by somebody.
It's still spam, and anyone sending/forwarding it is personally
responsible for their choice to do so.

It's abuse.  If you pass it on, you become an abuser.  So don't do that.

(Yes, I realize that it's not possible to achieve perfection, but that
isn't an excuse for failure to keep trying, continuously.  It's not
difficult to block 90% of spam using simple, free measures that rely
entirely on open-source software and freely-accessible data.  There's
thus no valid excuse for not doing at least that much -- today.)

> If that person then reports such messages -- that they have EXPRESSLY requested
> be sent to the receiving system -- as spam, to the operator of the receiving
> system, then that person is *indisputably* IN THE WRONG for doing so.

Nope.  If it came from YOUR system/network, it's YOUR spam.  If you don't
want to have to deal with the fallout from that, then don't send it and
don't forward it.

If that's difficult -- say, because other people out there are sending
spam addressed to your users on your systems who happen to be forwarding
their mail -- then you need to direct your attention to those other
people, because they're not doing their jobs properly.  If they are
unresponsive to your comments, perhaps you might reconsider the decision to
grant them the privilege of sending mail to your network.  After all,
if you've been generous enough to allow this, and they have repaid your
generosity by shipping you abuse instead of mail, then it seems silly to
continue to allow them to do it.

	"[...] if you give people the means to hurt you, and they do it,
	and you take no action except to continue giving them the means
	to hurt you, and they take no action except to keep hurting you,
	then one of the ways you can describe the situation is "it isn't
	scaling well."

                --- Paul Vixie on NANOG