Global sender whitelist -- November, 2002




Ending the age of anonymous SMTP servers through


a global registration infrastructure.






In order for the pay2send infrastructure to reach critical mass,
there needs to be an easy way to add pay2send functionality to
e-mail servers that are already running, rather than demanding
that people migrate to pay2send e-mail addresses.  By making the
server software available, pay2send features can be added to an
e-mail server in much the same way that spam deletion systems are
currently added.  Also, to eliminate redundant registrations, it
would be nice to have a central source for authenticating senders.


Towards the end of pay2send becoming a central point of authenticating
and accounting in e-mail infrastructure, we propose establishing
a "real-time whitelist" of known and authenticated e-mail senders and
the machines they customarily send their e-mail through.  This is
to be called the "pay2send global whitelist" and has two sections:
sender/relay pairs and known VERP sources.


Consider an e-mail getting sent
from dave@davidnicol.com to info@tipjar.com.  This e-mail is a
normal e-mail, not a mailing list message, so the envelope sender is
dave@davidnicol.com.  Let's say that "dave" is using the dial-up
modems at university of missouri (kansas city) and has their e-mail
software (aka "MUA") configured to relay by way of  the recommended
machine for that purpose, smtp.umkc.edu, which is open to e-mail
originating within the UMKC domain and has IP address
134.193.143.159.


When tipjar.com's e-mail post office software (aka "MTA") , which
for the sake of this example has been configured to use the global
whitelist, receives
the connection from smtp.umkc.edu to deliver the message, the first
thing it might do is run a RBL check.  Assuming that went okay,
after establishing the connection and issuing SMTP HELO or EHLO greetings, smtp.umkc.edu tells tipjar.com is who the mail is from,
in this case "dave@davidnicol.com." 


Tipjar.com, in the role of the receiving MTA, looks up


"verps.davidnicol.com.via.159.143.193.134.whitelist.pay2send.com"
to see if this machine is a known mailing list server for lists with a return address at davidnicol.com.  "dave" is an absurd VERP, but by always checking we avoid sending any verification codes to variable envelope return path addresses, which would get misinterpreted by mailing list software.  To get a VERPS listing, a machine's postmaster would have to verify the listing.  Instructions for requesting this listing are in the verification codes.  We should cause spurious unsubscriptions for exactly one user per VERPing mailing list server.  (It is probably best to skip the VERPs check unless the user part of the envelope return address is longer than, say, twenty characters.  This is merely a tuning issue however.)

smtp.umkc.edu is not a mailing list relay for lists that bounce to
fake but unique addresses at davidnicol.com,  so


"dave.at.davidnicol.com.via.159.143.193.134.whitelist.pay2send.com"


will be looked up to check if dave@davidnicol.com has been known to
send messages out through the machine at 134.193.143.159.


The DNS software used to store this information is the same software
which is currently used to store the real-time blacklists for open relays.
In response to a query, it responds indicating either than the query
refers to something that is on the list, or is not on the list, and these
results are cached by local systems. 


Reversing the numbers in the dotted quad IP address, as in the
in-arpa domain used for number-to-name mappings,
gives us the chance to delegate maintenance of the whitelist for a domain
to the administrators of that domain, provided that they adhere to the
pay2send policies and procedures which will appear on these pages as
they become clear.


Let's say dave just started at UMKC and this is
the first e-mail he has sent to anyone at a "global whitelist enabled"
e-mail server. When the receiving MTA receives the negative lookup
responses from the DNS system, indicating that the e-mail peer is neither
a mailing list server nor a known source for e-mails from this sender,
it issues a "451 sender not yet validated in global whitelist" error code
to the sending MTA, so the sending MTA will queue the message and try
to send it later.


The whitelist system, which has received this new request that it hasn't
had before, generates a verification code for adding this sender via
this relay to its database of known-good senders and e-mails this
verification code to the sender.  As soon as the sender returns it, either
via reply mail or by following an embedded hypertext link, a new entry
is made in the whitelist DNS and the next time the delivery of the
message is attempted (after the cached negative result expires, or course)
the receiving MTA will get a positive result from the whitelist and
will issue a "250 okay" reply to the "Mail from:" command from the
UMKC SMTP server, allowing the mail delivery to proceed.


Some organizations, such as national internet service providers, use a
network of outgoing SMTP relay machines.  Initially, the global whitelist
will insist that users of these ISPs authenticate against all the outgoing
relays their messages emerge from. It should be possible to correlate
the sets of relays that multiple users all use and have approval on one
of a set imply entry into the whitelist DNS on all of them. In fact if
the database is maintained using a file system, it will be possible to
combine multiple smtp relays under the same administration into one
virtual entity by making their IP addresses all point to the same
directory using symbolic links in the file system.  This will require
some modification to the RBL-DNS software, but nothing intractable.


The message also has a way to report forgery and abuse, in case the
putative sender did not send mail through that relay.  And a way to
report that the server is a mailing list server.  A "web of trust" system
for verifying legitimate mailing list servers must be set up.  That's a
whole new piece of work.


By using the global whitelist, a MTA is almost assured that all incoming
mail is  from authenticated senders.  Rather, spoofing of senders is
limited to senders who use the same outbound relay that you do.  So aol
users will be able to pretend to be each other, etc., but it will not be
possible for evil operators using open relays to pretend to be sending
messages from webmail accounts and get by the system, unless they
actually go to the trouble of using the webmail systems and go to the
trouble of registering their contrived webmail addresses every time they
switch them.


How the global whitelist benefits pay2send.com -- why pay2send.com
is setting this up:


Having determined that it makes more sense to offer a pay2send product
that can be added on to an existing MTA rather than insisting that
everyone who wants to shift e-mail costs back to the senders must switch
their e-mail address,  the global whitelist is the first step in this
direction.  Later steps will include exporting the databases of required
payments for unapproved senders and senders' maximum payment amounts
through another open interface, possibly DNS as well, possibly
XML-RPC, and a framework for registering your e-mail domain as a
project participant so that your MTA software can register payments
due in daily batches, and have the funds distributed among your
recipients, through tipjar transactions.


The global whitelist is less intrusive to existing processes than
per-domain solutions like TMDA (tmda.net, look at it and read the
FAQ there.)  In particular,


* no tagged messages. machines sending tagged messages are
identified by a second whitelist, for compliance with
message tagging.


* one confirmation message every time you change ISPs
validates you for all participating e-mail domains
instead of confirmation messages arriving variously as one
corresponds with various correspondents




What is needed to set up the global whitelist:




At this time, the pay2send project requires a main whitelist server
on a static IP address, and mirrors for load reduction and balancing.


REQUEST FOR PROPOSALS




If you are willing to donate hosting of this machine or accept tipjar.com
debt for payment for hosting service, please contact 


pay2send-whitelist@davidnicol.com


with your answer to the question, how much would your company need to
be paid, for bandwidth, per million dns lookups, to add mirroring the
whitelist.pay2send.com dns domain to the services you provide the
world.


What we're looking for are enthusiastic partners happy o help
host this service in exchange for "hosting services donated by ... "
listings in the pay2send whitelist documentation.


Some requirements:


It's important that the various mirrors of the service are fully redundant
and able each able to update the database if the others fail: we are
providing a robust infrastructure that we are expecting people to rely on
and if the whitelist suddenly stopped working, large numbers of total
strangers would be greatly inconvenienced as their legitimate e-mails are
suddenly no longer able to get through.  So each full whitelist server
needs to be able to play the part of the verification code recipient
by running at least a limited SMTP service so that they can all function
as MXes for addresses@verification.whitelist.pay2send.com.  The
whitelist servers will need to communicate amongst themselves to keep
the database consistent, perhaps though a nntp-like peer-to-peer batched
information dispersal protocol; perhaps through something like
http://freshmeat.net/projects/drsync drsync.  Although all that is needed
is to create the files that are missing.  Each machine can be responsible
for timing out its own non-accessed records.  So that means sending
out a complete list of recently accessed records every week or so, so
ones that have been requested can be marked as active.  Inactive
records get forgotten after six months or so?  And the postmasters of
installations with multiple outgoing relays need to be able to update
their server lists, or these correlations need to be automatically
synchronized too.  A dynamically repairable spanning tree would
work -- when one node's "upstream" peer fails, that node would
try to reestablish an update peering relationship with other nodes,
based on ping time.  If every node has a complete list of the other
nodes,  each node could exchange keepalive data with three other nodes
to create a spanning tree, and could attempt to contact backup nodes for
updates as failures occur.  Although research into design and
implementation or distributed high-availability clusters (what I just
described, sort of) might be a good master's thesis topic (Scholarships,
anyone?) i think the whitelist DNS servers would work fine with about
seven machines evenly distributed around the world, that all maintained
constant TCP connections with each other for updating purposes, and
simply sent out the same message on all six channels, including some
redundancy for those situations where, say, node B can reach node F and
node C can reach node F but node B cannot reach node C, a way to
recognize this and have node F forward updates from B to node C. 
Redundancy is fine here; node B needs to spool its update staus re:
node C until it receives notice from node F that node C has in fact
been updated.  Possibly even signed with node C's key, just for the
paranoid.  I tend to trust my upstream ISP, but I'm a pollyanna in
many ways.


So anyway, this project needs some volunteers with static IP addresses
willing to host a DNS server, which can easily function as an
information feeder for their existing DNS server if any.  I think
I've already got two so far but I need to check.


What a grand idea! Why is pay2send a dot-com instead of a dot-int?




Tell me about it.  Seriously, yes I think it's a grand idea and yes I
would very much appreciate receiving grant money.  If you are a
compentent and professional grant application writer who believes
they are able to apply and receive grant money to help make this
project happen, I want you on the team.  Please write to the
above address to make yourself known.




david nicol, 26 November 2002; happy thankgsgiving :)