Subject: Re: [Asrg] 3. Requirements - Non Spam must go through

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 10 Jul 2003 00:42:53 -0400

Going back to the original question 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06391.html):

"Any measure for stopping spam must ensure that all non-spam messages reach 
their intended recipients."

Am I correct in assuming that the overall opinion of the group seems to be 
that this statement cannot be part of the requirements? 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 10 Jul 2003 11:17:30 +0100

> that this statement cannot be part of the requirements? 

I think "must ensure" sets the bar way too high. I think that either the
sender, intended recipient or (possibly) both, must be able to determine
that a message wasn't delivered because of some anti-spam thingy.

--

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 07:37:02 -0400

From my perspective I believe that is correct.

Chuck Wegrzyn

Yakov Shafranovich wrote:

> "Any measure for stopping spam must ensure that all non-spam messages 
> reach their intended recipients."
>
> Am I correct in assuming that the overall opinion of the group seems 
> to be that this statement cannot be part of the requirements?
>

---

From: "Pete McNeil" <[email-masked]>
Date: Thu, 10 Jul 2003 09:40:29 -0400

I think you are correct.

For my opinion, it cannot be a requirement because the definition of
spam and non-spam is inconsistent, and because no mechanism for
determining this is perfect.

No doubt that it should be a _goal_ however.

_M

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Yakov Shafranovich
>Sent: Thursday, July 10, 2003 12:43 AM
>To: [email-masked]
>Subject: Re: [Asrg] 3. Requirements - Non Spam must go through
>
>

---

From: "Richard Johnson" <[email-masked]>
Date: Thu, 10 Jul 2003 07:40:13 -0600

> that this statement cannot be part of the requirements?

I believe you are correct.  You are certainly correct that the statement is
not an acceptable requirement for my systems.

Both as a matter of practicality, and as a matter of policy here, we block
entire networks.  We consider spammy networks a security issue (DoS), and
engage the same protection techniques we would against other exploit
attempts.  This means that effectively no mail from the networks we
consider pro-spam gets through.

Putting it another way, the network is irresponsible or otherwise a bad
neighbor, and thus too great a risk, so we drop all their SMTP connections.
A requirement to instead accept their mail and spin cycles analyzing it for
spammishness is simply not going to fly here.

Richard

---

From: "Elric Pedder" <[email-masked]>
Date: Thu, 10 Jul 2003 11:03:06 -0400

> Behalf Of Jon Kyme
> Sent: July 10, 2003 06:18
> To: ASRG

> > Am I correct in assuming that the overall opinion of the 
> > group seems to be that this statement cannot be part of the 
> > requirements? 

> I think "must ensure" sets the bar way too high. I think that 
> either the sender, intended recipient or (possibly) both, must 
> be able to determine that a message wasn't delivered because 
> of some anti-spam thingy.

I agree with this.  I would be careful about the wording though,
as the requirement "must be able to determine" may be met by
message tracking systems which the sender must manually invoke.
When someone sends an e-mail, until they hear otherwise they
should assume that it has reached its recipient in a timely and
readily readable manner.  That means that it hasn't ended up in 
a rarely read spam-trap and has not been silently dropped.  
This can be achieved either by (1) having the receiving agent 
issue a notification that the messages has been refused, or (2) 
by having one of the MTAs in the chain reject the message.

(2) is better because there is the risk that (1) may also be
rejected or classified as spam, and because (1) results in
considerable effort on the part of the receiver.  (1) should, 
however, be a DSN without return path to prevent loops.  An 
attempt to notify sender is probably sufficient.

I still believe that in order to maintain the end-to-end nature
of SMTP the solution "must ensure" that the message is either
delivered (to all the recipients' agents) or rejected (resulting 
in sender notification, subject to upstream MTA fulfilling its
responsibilities).

-- 
Elric Pedder
Mailtraq Development (www.mailtraq.com)

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 10 Jul 2003 11:37:27 -0400

> that this statement cannot be part of the requirements? 

  Yes.  I would re-phrase the statement, by adding a final condition:

    "Any measure for stopping spam must ensure that all non-spam
     messages reach their intended recipients, unless the intended
     recipients indicate otherwise."

  With some additional caveats:

 a) the recipient SHOULD be notified of any potential non-spam
    messages which were blocked, and SHOULD be given the opportunity
    to indicate consent to receiving those messages

 b) the recipient SHOULD occasionally be informed as to the nature of
    the message filtering, and given the opportunity to update their
    statement of consent (or non-consent)

 c) if there is no communication from the recipient as to the nature
    of his or her consent for some time period, the anti-spam system
    SHOULD remove all filtering, and assume that the recipient
    consents to all traffic.

  The purpose of (a) is to keep the recipient "in the loop" that there
may be messages of interest.  The purpose of (b) is to verify that the
anti-spam system is implementing the consent of the recipient.  The
purpose of (c) is to try to avoid dropping valid messages, due to
network problems, or implementation bugs in the anti-spam system.

  i.e. When in doubt, force the recipients to re-state their consent.

  I would also add another implementation caveat:

  d) anti-spam systems MAY exchange consent information.

     e.g. an ISP informs his upstream provider that ip-range/mask may
     be blocked from sending data to port 25.

     For the purpose of anti-spam systems exchanging consent, the
     system sending consent MUST be treated as a recipient, and the
     above conditions (a) through (c) MUST be applied.

 i.e. For the purpose of an upstream provider, a downstream ISP is
just another "recipient" of network traffic, with which consent may be
exchanged and enforced.

  The consent of the ISP is the sum total of the consent of the ISP's
customers, and the ISP's consent.  But for the purposes of exchanging
consent with the upstream provider, the ISP claims ownership for *all*
consent statements sent to that provider.

  Alan DeKok.

---

From: Walter Dnes <[email-masked]>
Date: Fri, 11 Jul 2003 06:34:15 -0400

On Thu, Jul 10, 2003 at 12:42:53AM -0400, Yakov Shafranovich wrote
> to be that this statement cannot be part of the requirements?

  Correct.  It's simply not possible in the real world.  Imagine a
constitutional amendmant that said no court system can impose jail
terms, fines, or other penalties unleass it could 100% guarantee that no
innocent person would *EVER* be convicted.  All criminals would go free.

  There have been observations and explanatory comments from others that
I would summarize as follows...

  - The risk-reward ratio should be the recipient's decision, i.e.
    informed consent.  This implies that individuals should be able to
    customize their filters...
    a) Spammers should not be able to dictate to individuals any
       restrictions on their spam filters/blocks.
    b) Similarly, ISP-wide one-size-fits-all rules don't work, except
       against the most egregious and foolhardy spammers.  One exception
       is that ISPs should be able to firewall/null-route and otherwise
       block systems that put excessive demands on the ISPs' resources,
       which threaten the integrity of the IPS's inbound-email system.
  - In order to get informed consent, some form of reject-logs should be
    available to the end-user on a regular basis so that users have the
    opportunity to monitor their filter's effectiveness.  E.g. I get a
    monthly log extract from clss.net listing all transactions blocked
    by my personal blocking rules.
  - Informing sender of non-delivery is a thorny issue, due to scum who
    forge addresses of innocent third parties as the source.  Strict
    compliance with rfc's can result in the mailbombing of those innocent
    third parties.  Doing the blocking at the MTA and terminating the
    SMTP session with an appropriate 5XX message is the preferred
    solution.
  - While accepting-and-tagging suspected spam is technically
    rfc-compliant, it can result in email being received and not read if
    the user doesn't feel like reading tagged emails.  This is
    effectively the same as dropping without sending a reject message or
    bounce.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did