From owner-nanog@merit.edu Sat Feb 26 13:42:19 2005 Date: Sat, 26 Feb 2005 10:27:40 -0500 From: Rich Kulawiec <rsk@gsp.org> To: nanog@merit.org Subject: Re: AOL scomp

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.

"Spam -- it's about _consent_, not *content*." If I, the forwarding system operator have the _consent_ of the mailbox owner on the destination system to forward messages to him, they are *not* spam on _that_ system. This *is* a separaate issue as to whether or not they are spam _on_the_forwarding_system_. Yes, the forwarding system should do everything "reasonable" to suppress spam from (a) reaching the local inbox *or* (b) being forwarded, if the customer has requested mail forwarding. If the recipient has a problem with receiving the forwarded message, he should complain _to_the_FORWARDING_system_ about it. *NOT* to the destinaiton system.

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)

How about various 'spamtrap' mailboxes, auto-forwarded to a central location for "further processing"? <evil grin>

...

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.

NOT AT ALL. It *IS* 'unsolicited' on _my_ system. It is *not* unsolicited at the final destination system. Questions/complaints/help-requests should be sent *TO*ME*, not to the destination system. He's *MY* customer, too. I've got an incentive to 'make things right'.

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.

Suppose my user "manually" forwards a 'spam' message to an account of his on another system. And then _forgets_ that *he* did it. And reports it to *that* provider as spam coming from my system. Is this _my_ fault? IS spam originating from my system? Should I terminate this user for 'spamming'?

It's still spam, and anyone sending/forwarding it is personally responsible for their choice to do so.

"It's about *consent*, not _content_." Want to try to deny that the recipient _consented_ to the forwarding from his other account? It is _not_ 'unsolicited' (the first word of UBE / UCE) on the destination system. It *may*well* be 'unsolicited' at the system where the customer has the forwarding mailbox. Complaints should be directed to *THAT* system operator, *not* the operator of the destination system. Note: I *agree* that "anyone sending/forwarding it is personally responsible fortheri choice to do so." The person that *made* that choice -- to forward that message -- however, is _the_customer_; the 'owner' of mailbox on the 'forwarding' system, *and* the 'owner' of the mailbox on the destination system. If "my customer" (in his identity on the receiving system) reports "my customer" (in his identity on _my_ system) as sending spam, should I terminate him from my system? After all, he's identified _himself_ as the spammer.

(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.)

Yup. Keep it from getting to the point it 'would' get to his inbox, and it won't get forwarded, either. But, if it _does_ get through, the recipient should be complaining about it _to_me_, not to the operator of the destination system.