On Thu, 17 Jan 2008, David MacQuigg wrote:
I don't like the term "luser", due to the attitude it conveys. The
I added the "l" since in this case the user's ignorance is pivotal. A
clued-in user knows that flagging forwarded spam will have no effect on
the S/N ratio of the forwarded mailstream, although it might kill the
stream entirely.
Then again, even with clued-in users, it's best if the MUA greys out the
"This is Spam" button for forwarded mail, since the user might fail to
notice that a particular spam was forwarded.
needs. That may not be as hard as it seems. In this case, I would have
an automated procedure for the Forwarder to challenge a spam report. The
absent-minded MD could then either confirm that he didn't make a mistake,
or just ignore the challenge and the report would be ignored.
I don't think that would work. If the default action, once a sender
claims to be a forwarder, is to cancel the complaint spammers would appeal
everything and hope the users are too lazy to re-confirm.
More importantly, an ignorant user just wants mail like the one he marked
to stop coming. For him the forwarding is an irrelevancy, so he'll just
reconfirm the complaint and we are back at square one.
Your solution is rather blue-sky. If we're talking blue-sky solutions,
it would be better to add a system to channel "This is spam" feedback back
to the forwarder, so that the forwarder can use the data for it's *own*
filter/blacklist training and the user doesn't need to worry over the
difference.
But a "forwarding problem solution" that tried to do that would be too
complicated to implement all at once. To reach that heaven, we need to
gradually build up a tower of protocols, each terrace offering a small
improvement for a small amount of work.
* Level 0: Status quo, people are afraid to use receiverside SPF.
* Level 1: TENBOX/E. Forwarder whitelisting is possible for power users.
The recipient asks his mail admin to whitelist mail bearing the SWK for
the forwarding relationship.
* Level 2: As Level 1, but a protocol is added to allow the Forwarder to
enquire as to whether his SWK is truly whitelisted by a given recipient
mailbox, allowing some idiot-proofing.
* Level 3: TENBOX/O. A means is provided for the forwarder to identify a
special mailbox to send automated requests for whitelisting. On receiving
a request, a TENBOX/O supporting ISP will then internally generate a
confirmation message and add the SWK to a whitelist if the recipient
confirms.
* Level 4: Means are added to allow the forwarder to collect "This is
Spam" results from the mails it has sent in the past.
I don't like the assumption that mail admins are dishonest if they
don't do things our way.
Honesty has nothing to do with it -- no lying is involved. But allowing
Problem B remains a Golden Rule violation.
If the recipient thinks it is OK to risk backscatter, he should tell the
forwarder to use the original MAIL FROM:, specify that SPF checking is to
be disabled for mail identified as a forward, and that any rejections from
his local spamfilter are to cause post-transaction bounces, not
in-transaction rejections.
Most people would say the above solution is very irresponsible, although
there is no less destructive way to guarantee that (non-forged) false
positives will be reported to the original sender. But in-transaction
rejection of a forwarded mail is even worse, because it additionally
displaces the punishments for this behavior onto someone else's MTA.
All that does is generate prejudice against SPF and anyone associated
with SPF.
My viewpoint is not the standard SPF one. The standard SPF viewpoint
(which I joined the list to fight) seems to be that forwarders should
solve Problem S themselves with SRS and just suck up Problems B and K.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=87358188-94111b
Powered by Listbox: http://www.listbox.com