spf-discuss
[Top] [All Lists]

RE: Email Forwarder's Protocol ( EFP )

2005-02-23 08:00:00
At 12:18 AM 2/23/2005 -0500, Guy wrote:

Dave said:

>when the recipient hits a "Reject as Spam" button. That reject should be treated as a "bounce" and follow authenticated addresses all the way back to its source.

I disagree!

I could create reject asbuttons all day. Reject as I dont like you any more. Should this also be treated as a bounce?

What about delete since it is spam, or delete because I just dont want to read it. Should these be treated as a bounce?

If a user makes the decision, no bounce. But I do understand that an automated system should send a bounce, otherwise if it was not spam, a valuable email could be lost. But a user pressing spam, trash or delete takes the risk of losing a valuable email.

The user could use the replybutton if needed!

A "reply" should only be sent if the user is confident the address isn't forged. The "bounce" alternative should be used for spam and anything else that needs to go back via an authenticated path. Giving users a bounce option will avoid mistaken complaints to the wrong address.

This does not mean automatically forwarding every user-level bounce. As you say, users can make bad bounce decisions. Users are, however, our best reporters of new spam that gets past all our blocks and filters. We should make it very easy for them to "reject as spam", and not spend any more time than is necessary for them to look at the item and make a good judgement that it is spam.

So what should we do about over-zealous spam reporters? The first bounce always goes to a sys admin, where a decision can be made as to whether to handle it locally ( maybe a site-wide block list ), bounce it to the previous forwarder, or report it directly to the domain-rating services.

-- Dave



*************************************************************     *
* David MacQuigg, PhD              * email:  dmq at gain.com      *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com