Meng Weng Wong wrote:
Recently I've been thinking about what a Next Generation Email
Architecture might look like. This is useful to think about because
then we can see what SMTP+SPF has in common with those possible
futures, and where the differences lie.
I think we can agree that a final solution has to match the aesthetic
of the Internet itself: no proprietary/closed/commercial/centralized
modes of operation; no "we'll start by shutting everybody out" gated
communities. This is why I don't see a permanent future for antispam
companies: their niche will be squeezed by a paradigm shift.
Certainly,
spam will always be around as long as naive or misconfigured MTAs are
over-liberal in what they accept; but I want the average user to
stayout of reach.
Well, a good way to start thinking about this type of thing, is to list
out your requirements, and then try to design something that addresses
those requirements. From what you state above (and I agree with you),
one of the requirements would be that users could send their mail via
(preferably) any mail server, or, a defined set of authorized mail
servers (like SPF). We also need a way to properly identify the user
that sent the mail. Note, this is just ONE of many potential
requirements that we could come up with.
For a moment, let's say that we shall design a protocol to replace SMTP
and POP together with a single protocol with two modes of operation,
receiving mail, and sending mail. For a user to get their mail, they
will most likely have to connect to a specified server where all their
mail is routed to for storage until retrieval, however to send mail, we
want to allow them to send mail via any mail server. Open relay's were
great until they began being abused... What if the server that houses
the user's mailbox creates them a digital certificate or private/public
key pair when the mailbox is created, which their client receives from
the server via password authentication and stores locally? The server
could then manage rotation of keys/certs, and keep the user's client
updated. Then, any time they are sending mail, their client signs (or
even encrypts) the mail with the key or uses the digital certificate to
prove who they are. Any server receiving mail from a client could in
turn verify the certificate with the server that actually houses the
user's mailbox and manages that user's key/cert. Basically, you build a
kind of PKI into the mail architecture. This should address both
requirements of allowing users to use any mail server to send, and
adequately identifying the user sending mail.
Short of djb's IM2000, overhauls of SMTP tend to add more fields to
the envelope: cookies that can be confirmed, etc. While an SPF
rollout does
imply MTAs have to be "patched", by "patch" we really mean "add a
plugin". Adding fields to the envelope requires changes to the very
core of an
MTA's SMTP logic.
Right now the envelope sender field conflates two concepts: "where do
i want bounces to go" and "who really sent me this message". Add
.forwards to the mix and you get "did another version of me send the
message?"
This is why I believe that modifying SMTP will never accomplish the
desired result. Not only was it designed to be open and anonymous, but
it's already established and getting MTA developers to add any extended
functionality to SMTP is a chore. By creating an entirely new protocol,
providing it as an alternative, and letting it gain critical mass on
it's own merit, I believe there is a better chance of succeeding in
reaching the desired result, which is a better mail protocol (and
stopping (most) spam at the same time).
---
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com