Jon Kyme wrote:
How about we look at a case where the forwarder has no profit, just cost:
debian.org. Many debian.org users use their addresses as a general
purpose
address, with the intention that they will always have it, to forward
wherever they go.
OK, debian.org are providing the "appearance" of a mailbox for no charge.
Jolly good. Well done.
In many particular cases, that 3rd party is a large ISP corporation
that has no profit motive to let end-users selectively disable
filtering of some of their mail. Thus, debian.org, ostensibly an agent
of the recipient, is forced to bear a cost (taking responsibility for
the message in the eyes of the recipient ISP) in place of the sender.
Indeed, that's the point. debian.org *are* sending this mail to
isp.example. They're doing this as the agent of a person who is a customer
of isp.example They are not doing this *for* isp.example, they're doing
this *to* isp.example
isp.example hold debian.org responsible for sending it. What's wrong with
that?
If isp.example users can't modulate the filtering behaviour to pass-thru
the debian.org routed stuff and some LMAP-thing is active - this will be a
hostile environment for forwarding. debian.org have a number of
alternatives:
1. do the rewriting (and accept some implied responsibility?)
2. refuse to rewrite and get blocked by systems which don't like the look
of mail from example.com routed via debian.org
3. Provide a real mailbox, POP / IMAP.
Perhaps what we need is some standardized way for the
recipient/forwarding user to authorize the message in advance of any
filtering. Unfortunately, that probably won't be effective in this case
unless we got an ESMTP extension designed for it, because ISPs want to
filter as early as possible in the transaction.
Ideally, a system running LMAP-thing should give users the ability to
configure it in such a way as not to be forwarding-hostile. If there's no
"profit-motive" for supporting this, it suggests that customer demand is
too small.
I'm very much in favour of some standard for configuring filtering at the
ISP. However, I can't see how one could make this a pre-requisite for LMAP
deployment.
It seems possible that widespread adoption of LMAP-like systems could
increase costs for forwarders. I don't believe there's a rule which says
that the forwarders p.o.v. is more significant than the receiving ISP's.
The feature that allows debian.org to forward transparently has costs.
Spome of these costs are currently borne by mom&pop.example.com when their
little mail server chokes on 50k bounces an hour from yahoo for spam they
didn't send.
The costs of spam at isp.example are passed onto the user, they have a
business model which supports this. If the forwarder doesn't have such a
business, they may have to reconsider the services they offer.
Omelette v. Eggs, I suppose, or, better, TANSTAAFL.
Perhaps it's time to suggest a different approach for forwarders.
Since forwarders are clearly trusted by the user, we should make it possible
for the forwarder to deliver directly to the user's inbox, rather than
transferring messages like any other mailer. What if the user had the
forwarding system connect to his IMAP host and inject the message there? The
biggest problem I see with this is that it breaks multiple forwarding and
intermediate filtering (viruses, procmail/popfile sorting, etc.). If it
injected to a special folder, that would be solved, too. Now we just need a
standard way to carry this out for forwarders to implement.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg