I agree there are circumstances where anonymity may be acceptable but in
these cases it is most definitely not.
Validating and/or tracing human identity is *not* an email issue any
more than it is an http-retrieval, ftp-upload, instant-messaging,
etc. issue. It's a fairly general issue on the Internet; in some
areas, *viewing* certain materials that you mentioned is a criminal
offense, so it needn't be emailed, though it could be uploaded to an
ftp site and still be a criminal offense, of course.
NG email therefore should not *structurally* reject anonymity any more
than it does today. Otherwise, it'd be much less useful than today's
email, see much less-wide deployment, and probably wither on the vine.
It *should* clean up aspects of injection, transport, and delivery
(see my other long post, regarding moving pertinent information out of
the header and into the envelope for how) such that entities other
than the originator (the sender) are more-easily able to examine the
"history" of the email's progress.
And it *should* offer easy interfaces (via its protocols, e.g. how
envelopes are written and parsed) to whatever external facilities
exist to get info on transport agents.
But you can reject anonymous email *now*, by basically going through
the following steps for an incoming email via SMTP:
1. Do I trust the injecting host/IP to properly form the
topmost "Received:" header?
If no, reject the email.
2. Is that host/IP representing the email as originating on a
system under its control?
If yes, go to step 6.
3. Examine the next "Received:" header, starting with the topmost
one.
4. Treat the host/IP in that header as the "injecting host/IP"
for the purposes of this subroutine.
5. Go to step 1.
6. Do I trust the injecting host/IP to correctly designate and
track users who submit email?
If no, reject the email.
7. Does the injecting host/IP promise that the user submitting
this email is not anonymous, and do I trust that promise?
If no, reject the email.
8. Accept the email.
The main hassle here, as far as I can tell, is parsing the "Received:"
header, plus whatever variations exist on how those header lines are
treated by weird/buggy MTAs.
Also, I don't know of a clean, consistent means to deal with Step 7,
in cases where it's truly the injecting host/IP, and especially in
cases where it's relayed email. Here, a generalized, improved version
of IDENT might be just the ticket, if the originating host/IP hasn't
already promised, via some info on the envelope (in today's email, in
the header), something useful about the submitting user. But, often,
that sort of info is preferably omitted, and provided only when
requested, to avoid exposing too much info to the outside.
The point is, a NG email system cannot, by its mere existence, enforce
trustworthiness of systems on the Internet, nor of its users to not
hide their identities.
And since you can do the above *now* with the current email system,
about all an NG email system can offer above the current system is
more fine-grained responses to, and negotiability regarding,
situations involving less-than-fully-desired trustworthiness.
We need protocols to allow systems to exchange information on trust,
on identities, and on *traceability* of identities. There's an
important distinction between the last two: "who exactly is
joe(_at_)example(_dot_)com?" is a more insistent, or narrow, question than "do
you promise that you are able to reveal the identity of
joe(_at_)example(_dot_)com under certain circumstances, such as a court order?".
But those protocols are needed for much more than email, since email
addresses are not the only way people identify themselves to automated
entities on the Internet (consider IRC, AIM, ICQ, whatever those
things are). So "who exactly is uploading via 192.168.0.5:5411?"
should not really seem like a much-different question to whatever
facility handles queries about identity.
So inventing these protocols may be necessary, but requiring their
presence as part of NG email means making NG email more complicated
than it needs to be.
Also, it doesn't really matter that much what the US Federal
Government requires in terms of traceability, as long as NG email can
*accommodate* that by making it easy for sysadmins in the US to
specify such requirements.
NG email shouldn't be seen as a means to impose US Federal law on
everyone who wants to send email anywhere in the world.
But having most or all US-based MTAs configure NG-email systems to
require traceability may well have the desired effect anyway.
--
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>
--Fix qmail's qmail-smtpd so it doesn't crash on a big header line:--
<http://www.qmail.org/netqmail/>