Re: Proposal For Token-Based Authentication In Mail Submission As Anti-Forgery Effort

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]