Michael Deutschmann wrote:
On Wed, 6 Feb 2008, David MacQuigg wrote:
Problem P - Recipients have difficulty keeping track of and updating
their forwarding arrangements.
These aren't like the three forwarding problems I've laid out.
Problem P is a root cause of my three problems, but is not a forwarding
problem in and of itself.
It's not even THE root cause -- it shares credit with recipient
indifference to the other forwarding problems.
Perhaps it is rather a symptom than a problem. The symptom tells that the
email transport system lacks something that is quite fundamental in a
communication system. Historically, both surface mail and telephone agreed
that the caller pays the expenses while the callee has no obligations.
Email puts it rather differently. Indeed, it used to be a mere utility for
exchanging messages until a decade ago.
I cannot claim that solving problem P affects the more forwarding-specific
problems S, B, and K. However, the only kind of solution I'm able to
imagine for solving P -namely keeping track of message paths- provides for
coping with S, B, and K too. Let me put some examples below.
If:
* legitimate mail from <sarah(_at_)example(_dot_)com> to
<fred(_at_)example(_dot_)org> is
forwarded to <ralph(_at_)example(_dot_)net>, run through SpamAssassin by
example.net
and then delivered to Ralph's mailbox.
IMHO fuzzy filtering should stay near to the end, possibly on Ralph's MUA.
However, different people may have different opinions on different
filters. By tracking forwarders along message paths, collecting each one's
capabilities along the way, Ralph could be able to configure what filters
will be activated where, for messages destined to him.
* false-postive mail from <sarah(_at_)example(_dot_)com> to
<fred(_at_)example(_dot_)org> will
be bounced to <sarah(_at_)example(_dot_)com> when Example.net 5xxs example.orgs
the attempt to forward to Ralph.
Forwarding occurs for different _reasons_, ranging from mailing lists to
anonymization. Bounces are meaningful in certain cases and useful for
specific actors, and should be directed accordingly. It is the recipient's
responsibility to classify each forwarding recipe properly.
* actual spam, forged in <sarah(_at_)example(_dot_)com>'s name and sent to
<fred(_at_)example(_dot_)org>, will also be bounced to
<sarah(_at_)example(_dot_)com> when
Example.net 5xxed it.
When forwarding will have been fixed, example.com and example.org will
have no excuse for not enabling SPF, resp. publishing and checking.
...then Forwarding Problem B is active. But Ralph doesn't mind. If his
spam-filter triggers, he doesn't worry because he knows the original
sender will know from the bounce that the mail wasn't delivered,
(The sender will also know the implicitly leaked target mailbox name.)
and if it
was indeed spam, he never had to acknowledge seeing it.
Sarah will be angry about the backscatter, and will sic the Lumber Cartel
(TINLC) on Example.org, but Ralph *doesn't care about that*.
Privacy directives also address direct mail. Whether opt-in or opt-out
would be enforced under specific circumstances, no evidence that either
has ever occurred is currently being collected, thereby clogging any legal
action.
This facet of the (P) privacy problem is not very well expressed by its
current short description.
The only way Ralph will care is if Example.org *deliberately* breaks his
forwarding to punish him.
That implies communication between Ralph and example.org is at stake.
While example.org can always send automated messages to ralph(_at_)example(_dot_)net,
Ralph has to get personally in touch in order to reply. Tracking
forwarders yields reverse paths as an added value.
-------------------------------------------
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=93480809-37ff06
Powered by Listbox: http://www.listbox.com