On 6 Mar 2004 at 8:08, Vernon Schryver <vjs@xxxxxxxxxxxxxxxxxxxx> spoke, thus: > > 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. That should, you're right, be "Sender forgery". SMTP Auth is not carried from host to host and only guarantees some privileged user his rights, such as relaying or submission, during any given transaction; it doesn't permit an end-to-end verification of sender across multiple hosts, necessary for normal mail delivery. It doesn't (or shouldn't) prevent any mail from being delivered at all to a domain if the destination host is an MX for that particular domain, regardless of any details of the mail. There are issues concerning today's worms/viruses that make port 25- blockage on all but the local smarthost more plausible and reasonable, too, and the submission port won't take long to follow when the next gen of worms flood the net. I don't like it, y'know, but I'm ready to *grrrr* face it. It is, in summary, useless as a measure against sender forgery in short term, and I'm ready to bet long term as well, despite having its real uses as a trusted submitter/relay-permitted client authentication method. Good security practice to keep hackers from hopping your firewall and trying to relay through your system from a local vantage. PGP is strictly per-user, and isn't practical for mail delivery. Use of it for quality spam detection to any useful worth is akin to whitelisting, and PKI infrastructures and corporation-determined trust are a point of weakness (as you say, below). Same for StartTLS and S/MIME, even if TLS *were* encouraged to global use. If any of these were at all useful, they would either need to be updated and/or used and deployed almost immediately, which is obviously impractical. At least this means holds as much configuration and balanced (and uncontrolled) distribution as DNS itself, not to mention gentle backward compatibility. > 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. This proposal attempts exactly that! Other proposals we've seen all depend on administrative configuration which predetermines some particular aspect of mail delivery, i.e. IP addresses from which any given mail should emerge for a particular domain, all of which harm - as you say - legitimate transactions. This scheme leaves that choice to the user. Admins simply maintain a list of user-chosen passwords, and it is the user who, by providing the correct password to his MUA when submitting mail through his work's MTA under his Hotmail address, guarantees its delivery when, at the other end, the user's password (not his domain name, not his IP address) is verified against the same password at the user's home domain - Hotmail - by a query from his mate's MTA a moment later. > 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? Again: only the password is verified! Forgery is now dependent only upon the misuse of the password. The administration of the domain referenced in the envelope sender is now soley responsible for any of its spamming users, case by case, and there is no opportunity for a domain to be misrepresented provided those passwords are the cause of the mail's acceptance. That is the whole point! I *do* hope you read my entire message ... but let's suppose you didn't. If you are suggesting that all those things really *are* forgery, then I'm afraid I'm addressing the wrong person for comments. I'm going to suppose - to hope - that you don't. I appreciate your need for good sense and conservatism, all the while encouraging good and useful inovations in SMTP, and I'm trying hard to strike that balance. The sacrifice, and there always is one, is an additional piece of user information, a token. Only difference between that and the SPF is that the token is supplied by a user, not an administrator, and goes wherever the user goes. I believe in the use of TLS for security, in SASL for avoiding problems with IPV4 (spammers hopping ACLs to get relaying permission), for guaranteeing relaying when you need it in the car on the way to visit Auntie Jane, or whatever. I don't, though, believe in sitting at a local cafe in mexico and using my home MTA just to send out a bit of mail to the local hotel, particularly when my MTA sits here in the north of London, England! If you agree that this last situation is in fact plausible, then you are not being conservative. > - 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. No, I wouldn't be happy with such corporation or government-run trust, either. This is a problem of cryptographic PKIs, yes. Even now, the situation is troubling, with Key Escro possibly being the largest threat. As for the substantial problems inherent in other systems of key distribution, I'm interested in hearing the problems specific to mine. :-) This "Key distribution" is nothing more than a database or other simple client-server query made by a destination system. It is limited to sender forgery only - nothing less, nothing more. It depends on getting a yes/no answer from the domain owner's database in response to a password, all the while ensuring that the database itself is not available for public (internet) viewing. Keys are not even distributed, there is no trust relationship, no guy in charge. DNS holds only information about reaching such a database, both the DNS record and the database being under the jurisdiction - presumably - of the domain holder, if the database even exists. > - 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? You're right. This specification does nothing to address such a problem. Remember, though, that it was a mark of progress in spammer tactics when they stopped using non-existent domain names, all of which could be readily identified by a simple DNS query, and started using legitimate ones. This proposal does nothing to stop people from using legitimate domains under their own power to spam with, or even domains under someone elses' power if that domain chooses to support spammers or be negligent of them. Still, a lot of mail comes from domain names - legitimate, non- spamming domain names - whose systems were not used to deliver spam purporting to come from those domains, and whose administrators are very definite about their anti-spam policy - "No spam here". I'm pretty sure the effect of this sort of specification would make our desires felt, and a noticeable impact on our inboxes, just as SPF should. Having said all that, this specification ensures that the only people sending from a domain are those in authority to do so, whether truely or maliciously, so the envelope sender of a spam suddenly becomes music to the ears of a spam fighter and, thencefrom, a good solid RHSBL. The only kind of domain who would then suffer would be careless or uninterested domains, whose reputations tell their fate. > > 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? Yes. See above. If you are the guy I should be talking to, then you'll see at once why this isn't good enough. If you aren't, then you probably do see it as sufficient, almost in self-contradiction. Are you the guy? > What about SMTP-TLS with verified certs required? Yes. See above. PKI = bad. Also, I've seen more than enough bad implementations of this specification which, after a failed handshake of TLS caused purely by - say - the CA certificate of the sending MTA's cert not being in the list of the recipient as in self-signature for local benefit, would break and fail to consider a non-secure transaction for continuing the session. Thanks, but no thanks. > I hope you won't be too offended if someone points out > http://www.rhyolite.com/anti-spam/you-might-be.html Not at all. Read it already. Probably responsible for the very first line in my original message. You did read that, didn't you? :-) > I wrote it during the first months of the ASRG mailing list. Hmmm. I can see that now. It all makes sense. Cheers, Sabahattin -- Thought for the day: Intuition (n): an uncanny sixth sense which tells people that they are right, whether they are or not. Latest PGP Public key blocks? Send any mail to: <PGPPublicKey@xxxxxxxxxxxxxxxxxxxxxxxx> Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: <mail@xxxxxxxxxxxxxxxxxxxxxxxx>