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

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 19:59:09 -0400

At 07:23 PM 7/7/2003 -0400, Elric Pedder wrote:

> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Yakov Shafranovich
> > Sent: July 7, 2003 17:24
> > To: [email-masked]
> > Subject: [Asrg] 3. Requirements - Non Spam must go through
>
> > Just ran across this quote from the John Gilmore of the EFF
> > (http://www.politechbot.com/p-04927.html):
> >
> > ----snip----
> > After years of divisive discussions, a very similar
> > pledge/oath/policy was
> > what EFF was able to come to agreement on:
> >
> > "Any measure for stopping spam must ensure that all non-spam
> > messages reach
> > their intended recipients."
> >
> > Perhaps none of us has yet come up with a silver bullet to solve the
> > problem of spam -- but it IS within our power to solve the problem of
> > overzealous anti-spam measures.
> > ----snip----
>
>I don't believe you can stop false positives -- if only because
>people will have widely varying opinions on what SPAM (to them)
>is.  It is, however, very dangerous to allow false positives
>because if anything the perceived "reliability" of the Internet
>becomes compromised.
>
>I would recommend
>
>"Any measure for stopping spam must ensure that all messages
>either reach the intended recipient, or are returned to the
>sender, or the sender notified."

How would this fit within the consent model? If a RECEIVER revokes consent 
for a specific sender, then messages from that SENDER cannot be delivered?

Yakov  

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

---

From: "Elric Pedder" <[email-masked]>
Date: Mon, 7 Jul 2003 21:37:39 -0400

> Sent: July 7, 2003 19:59
> To: Elric Pedder; [email-masked]
> Subject: RE: [Asrg] 3. Requirements - Non Spam must go through
 
> At 07:23 PM 7/7/2003 -0400, Elric Pedder wrote:

[snip]

> How would this fit within the consent model? If a RECEIVER 
> revokes consent for a specific sender, then messages from that 
> SENDER cannot be delivered?

Within the consent model, notifications would be sent when
RECEIVER revokes consent or when SENDER does not have consent.

It is important in the revocation case because it is still possible
that consent was accidentally revoked by the RECEIVER.  

Note that the "notification" does not have to be, necessarily,
sent by the consent decision-making system.  Answering 5xx after
receipt of the message leaves the responsibility for notifications
with the sending MTA, or the client MUA.  RFC2821 provides 10
minutes for analysis of the message, which should be plenty of
time to assess whether or not consent is granted (including
analysis of the message content and DBL checks).

Independent (post delivery) notifications are a last resort, but
are still far better than simply dropping a message.

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

---

From: Pete McNeil <[email-masked]>
Date: Tue, 08 Jul 2003 01:03:59 -0400

>At 07:23 PM 7/7/2003 -0400, Elric Pedder wrote:

<snip>

>for a specific sender, then messages from that SENDER cannot be delivered?

Different RECEIVERS on the same system can have different policies. One 
RECEIVER might reject the message (revoked consent), while another accepts 
it (consent).

When the SENDER attempts to deliver the message to both recipients one will 
be accepted during the SMTP conversation and the other would not be.

If the policy was not clear at the time of the SMTP conversation then other 
mechanisms would be used to notify the SENDER that the message was rejected 
by one or more recipients according to the applicable policies.

_M

PS: I do not necessarily agree that the SENDER must be notified in ALL 
cases since there are forms of abuse that rely on this, however I would 
agree that it would be a "best practice". It should be implemented as part 
of any consent policy as an action to be taken when consent is 
denied/revoked. Legitimate bulk senders would then also have a best 
practice to automatically remove the RECEIVER from their list and 
unsubscribe them if they received such a notice. In any case, making these 
recommendations an indication of "best practice" would allow the 
specifications to indicate _should_ rather than _must_ which makes more 
sense for some implementations.