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