ietf-asrg
[Top] [All Lists]

Re: [Asrg] Opt-Out Notes: too complicated, ignoring history

2003-03-27 21:51:06
On Thu, Mar 27, 2003 at 11:13:45PM -0500, John R Levine wrote:
    1) "Banner" implies they occur on connection, however you don't yet
    know the policies of the target users until you get a RCPT command.

The banner displays the policy of the server owner.


Then it is, unfortunately, only a limited solution.   The problem is that
if it were the only solution, it would put a lot of pressure for conformity
on ISP users.  The whole site must make a simultaneous decision for all of
its users, and the only alternative is to leave the host (and change your
e-mail address) if you don't agree with the policy.  This is true both
for people who want an open mailbox at a site which wants to declare a
blocking policy, and those who want a blocking policy at a site that wants
open.

We would want to be careful about releasing a solution which solves some
people's problems and because it doesn't solve others, pidgeonholes them
into the site-wide approach, and thus does not meet the goal of providing
individual user choice.   

Every ISP has terms of service, no ISP provides an unlimited unfiltered
bit pipe to and from the entire rest of the world, and no ISP will receive
an unlimited amount of mail for its users.  It's perfectly reasonable for
the terms to say that they don't accept incoming spam unless you pay
extra, just like they say that your mailbox is only 10MB (or whatever),
and if you want to get bigger messages than that, you're ouf of luck
unless you switch to their higher priced service with bigger mailboxes.

It is indeed possible for most ISPs to change their terms of service on
their customers, however this would not meet the goal of facilitating user
choice, so this can only be one prong in a broader set of solutions.

If for some reason a server owner wanted to sell a higher priced service
for people who want spam, he could set up a subdomain with a separate
server (most likely on the same physical equipment) that doesn't say NO
UCE or NO UBE.

Indeed they could but that would require all those users to change their
e-mail address, something I think we are loathe to accept as a solution,
unless there are not other alternatives I hope you would agree.

The banners on a domain's MXes are the domain's policies.  If a domain has
more than one MX, it would be a good idea if they all published the same
policy, but that's not a technical issue.  Outgoing relays before the
transaction to the MX or incoming relays after that transaction don't
matter, since the MX is where the mail is handed from the sender's agent
to the recipient's.

But this makes the above forced-aggregation-of-decision problem even worse.
Not only must all users at a site have the same policy, but this must match
at all mail relayers.  Again, this seems very much at odds with the goal of
end-user control.  We would only adopt it if it became very clear that
end-user control was not attainable.

I think it's clear as well that this approach, though I used to favour it,
would quickly result in the same policy being applied to everybody, with
no alternative but to change your email address to express your will.

       All your MXs and other relays need to know the
       preference of every _user_ they relay for, unless they relay only for
       single-user sites.

This is the "every user's entitled to receive all spam" fallacy again.

I believe that many people do believe that it is ideal to leave the choice
of filtering in the hands of the end-user.  This does not mean, by the way,
that an ISP can't charge you for e-mail received by the megabyte above some
limit (as some ISPs do) as a way of strongly encouraging you to follow a
given policy.

But I don't believe the IETF would ever want to, in technical specifications,
push policy decisions on users or service providers.   Rather we would wish
to provide tools and protocols to implement policy decisions.   Many believe
in preserving the end to end nature of internet protocols as much as possible,
sacrificing it with great reluctance or not at all.

    3) Likewise, what do outgoing relays do?  For many mails, the user sends
       mail to an outgoing MTA, that relays to an MX, which relays to the
       target MTA.
That wouldn't be a good way to send mail that needs to obey a NO UCE or NO
UBE policy.  So don't do that.  Every ISP I know of doesn't let you send
spam through their MTAs anyway, so this would not be a change to current
practice.

Nonetheless it is the way mail works, and the relays are generally designed
to be "dumb" -- their job is to forward the traffic, not be involved in
decisions.   ISPs unfortunately have many definitions of spam in their
TOS, and while that might be reconciled, in some cases users may not even
be aware that they are using a relay.  Some ISPs redirect traffic on port
25 through their relay, no matter what IP you attempt to send it to.


This proposal does make it somewhat harder, but not overwhelmingly so, to
send UBE or UCE to people who will accept it.  I don't see that as a
problem, since it pushes the cost of spamming back on the spammers.  It's
a content neutral (for NO UBE at least) time and manner regulation.

Indeed, it's much more workable on the UBE side of things, but you have
made note of UCE as a possible policy a number of times, so naturally that
is a concern, since single mails will continue to be sent through normal
channels in which such a policy banner system would not be workable. 

This has the significant advantage over other proposals I've seen that it
doesn't require any software work by the recipient server operators other
than editing the server banner one time to add the appropriate text,
something that is easy to do with all the SMTP servers I know.

Actually, there are several proposals that work at this level.  About 6 years
ago, I even had an SMTP banner which made such a declaration, as did many
other people.

Which comes to the other point.   How effective would such a scheme be,
do you think?   One would presume that it would need laws to back it up,
but even then, but it's pretty clear now that laws resembling any of
the existing ones don't work, some would argue they never can in a global
net.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg