> From: "Sabahattin Gucukoglu"
> ...
> and important catch in this proposal, that being a modification to all
> MUAs and MTAs to allow the acceptance and carrying of a password token
> which should persist throughout the entire mail delivery, ...
> My proposal is a scheme for anti-forgery, which makes use of a non-blank
> token, or password, which can be verified by a recipient system ...
How does your scheme prevent forgery better than SMTP-AUTH, SMTP-TLS,
S/MIME, or PGP? Most MTAs support SMTP-AUTH and SMTP-TLS.
The difficulties in preventing spam sender forgery are not in defining
token protocols but in
- defining forgery in a way that excludes common, legitimate practices.
Why isn't sending mail with your Hotmail account as sender while
sitting at your desk at work or with your work sender address while
in a customer site, hotel room, or airplane "forgery" that would be
prevented by the proposed sender-verifying mechanism?
- key distribution.
Verisign/Microsoft would be happy become the toll collecter for
all Internet mail using the current or a variation of the current
commercial PKI. Some of us are not keen on that idea. All other
key distribution mechansims have their own substantial problems,
including those that would use the DNS.
- preventing spammers from buying as many tokens as they need.
The major spammer that currently calls itself Zhang Jun and Qing
Zhang has been burning several new domain names per day for the
last 2 or 3 months. Why won't it be able to make or buy tokens
to go with each of its domain names? Why won't domain2004.com,
managernic.com, namelite.com, nicsimple.com, sitesadmin.com, and
the rest of its DNS servers serve its SPF RRs or your password
tokens as readily as they serve NS, MX, and A RRs? Why can't it
replace those DNS servers as they become recognized with new DNS
servers, as it has been doing for years?
> 1. Sender MUA submits message through some host X, indicating token to X
> using the stok extension to be defined in SMTP as an extention to its
> "mail from:" command:
> mail from:<someone@xxxxxxxxxxx> stok=blorb
> ...
> 4. MX begins a password query. It must connect to some kind of password
> query resource. The MX may connect to a designated MTA for a domain and
> use the stok keyword to query for a password (>>"stok blorb" <<"250 Token
> is tasty!") or some other simplified database query. ...
> 5. Authenticated submitters are welcome, unauthenticated submitters
> aren't, policy-dependent. ...
Have you looked at SMTP-AUTH?
What about SMTP-TLS with verified certs required?
I hope you won't be too offended if someone points out
http://www.rhyolite.com/anti-spam/you-might-be.html
I wrote it during the first months of the ASRG mailing list.
Vernon Schryver vjs@xxxxxxxxxxxx