Where is the draft of it. Most banner proposals have had a number of
problems.
www.cauce.org/proposal, same place it's been for years
Please keep in mind that the point of his proposal is to provide a spec
for laws that want to provide server operators with a consistent way to
provide notice to senders that they don't want UBE or UCE. As Hamidi,
Compuserve v. Cyberpromo, and many other cases have established, server
operators are quite entitled to tell unwanted visitors to go away.
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.
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.
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.
2) There's no good way to deal with the question of legitimate relaying,
ie. MX records.
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.
I realize that you can construct scenarios where a mailbox on server A
without a NO UBE policy is forwarded to a mailbox on server B which does
have a NO UBE policy, but humans interpreting a law wouldn't have any
trouble dealing with that; if the forward was authorized by the user on
server B, it's solicited, if not, it's server A's problem to control his
network.
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.
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.
The only way to deal with this is to require the
outgoing user to label, so that the MTA which finally talks to the
final destination can know what to do if it's informed about a
policy after it issues the RCPT TO:
Not at all. They could either listwash before sending the mail (we have
sample code on the web site), or hire a mailing service that washes on the
fly.
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.
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.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg