spam block, spam block, spam block.


Just as the best practice in firewall maintenance is
to block everything and then only allow what you want in,
we believe that the best practice in e-mail filtering is
to block everything and only accept those messages that
you want.

Generally, people want messages from other people, and
from mailing lists they have subscribed to and read.  People
do not want mass-mailed advertisements, even when the senders
of these advertisements make dubious claims that at some point
someone "opted in" to something.

The pay2send system makes decisions based on the network address
of the SMTP peer messages are coming from, and based on
envelope return addresses.

For a message to get processed for relaying through a pay2send
SMTP server, either the message comes from a SMTP peer that
the recipient has approved in advance, the message comes from
a sender who is associated with the SMTP peer and the recipient
has approved that sender in advance, or the sender has paid money
into the pay2send system to pay the recipients -- and they are
sending through a SMTP peer that they have approved, in advance,
that they will be using and that mail from them from that server
is sufficient identity verification to debit their pay2send money account.

We believe that SMTP peer network address association is sufficient
security.  Consider, for instance, yahoo.com webmail. In order to
produce an e-mail from, say, davidnicol1187@yahoo.com, from the
normal yahoo.com outgoing SMTP relays, I need to log in to yahoo webmail
under that account.  Unless I'm perpetrating some kind of inside job
from within yahoo.com, there's no other way to fake a envelope return
address from the correct SMTP peer.  Faking an envelope return address
is completely trivial, but not faking an envelope return address _and_
the network address of the originating mail transfer agent. That requires
access.  And people who share a relay, such as a university
community, can masquerade as each other,
yes.  They can also resolve disputes among themselves.

Any sender with enough funds in their pay2send account to become
a serious fraud target for monetary gain is probably best off
forming a close relationship with their main SMTP relay.  Preventing
users on a multiuser system from sending out e-mails with each other's
envelope return addresses is an old, and solved problem which need not
be addressed here.


There are several systems available for protecting an e-mail inbox from
fake users.  TMDA is one, it seems that the old, high-powered unix
hackers (Larry Wall, Daniel J. Bernstein, etc) all have their own.
The pay2send.com "new sender or new relay" messages function as
a one-time verification step for validating a sender to all participating
recipients.

Initially senders using extensive e-mail systems such as yahoo or
earthlink might have to respond to three or four messages before
they are registered with all the relays in use at their ISP, where their
outbound e-mail might emerge from.  After a while (such as fall, 2003)
pay2send will be linking co-managed relays to each other so that registration
on one will imply registration on the others.

Mailing list servers.
pay2send sees the world of e-mail sources as strictly divided between
two types: relays and listservs.  At least at first, one SMTP peer
is going to be considered either one or the other.  Good listservs
rewrite the envelope return addresses on the messages that pass through
them so the listserv receives bounce messages and uses them to update
the subscriber data, rather than bounced mailing list messages returning
to the good people who post to the mailing list.  So we can't go
sending new sender registration queries to all the bogus return addresses
generated by mailing lists: that would not work.  For the first phase,
we allow mailing list servers to get identified as such, and recipients
can approve traffic from mailing list servers on a per-server basis, and
payment for receiving new messages is collected on a per-server basis.
That way, fine, upstanding, and professional advertising sources can
register their listservs with pay2send as such, and they can send
mail to pay2send-enabled e-mail servers, for which they must pay,
or else their mail will bounce. 

How to pay2send-enable an email address at a different domain ?
Have that machine forward the e-mail to an address at a pay2send-enabled
domain, and instruct the enabled domain in how to determine SMTP peer
from the headers in the incoming message.

How to pay2send-enable a smtp server?
Let's say for instance that @kclug.org wants to get pay2send-enabled,
instead of, or in addition to, using RBL and SpamAssassin for UCE prevention.
The administrators of the SMTP service on that server will need to
install some additional software, and they will need to apply for
pay2send peer status.  Since money is involved, there may be credit
checks or deposits required.  The exact procedure is still up in the
air at this time. After a smtp domain is fully integrated into the
pay2send network of smtp domains, the servers that handle that domain
will accumulate bills to senders and report them in periodic aggregate
transactions.  Also member servers will generate and handle new sender or relay messages, and process identifications of servers as listservs, opposed
to relays.

Creating mailing list products with pay2send
Let's say you have compiled a mailing list of twenty thousand avid
role-play gamers and you would like to sell this mailing list to manufacturers
of books and dice and miniatures and foam broadswords and whatnot. Using
pay2send, you can set a high price on sending to your mailing list.  And
using pay2send, the recipients on your list can demand their share of the
take.

10 December 2002