Mark Delany wrote: > Forgive me for a bit of an aside, sortof. > > A lot of people have long used the Postal Service analogy of being > able to supply an arbitrary return address as a justification for > doing the same in email (DC I'm looking at you, buddy). > > So did anyone catch the news today that UPS.com are planning to verify > the return address of a package against your drivers license? And that > other "postal" services may soon follow suit? > > In other words, the days of providing an unauthenticated "author > address" may be numbered in the physical world. > > It's all in the name of security theater of course, but nonetheless, > somewhat amusing in the DKIM context. > > Mark.
Hi, At least for us, the "return path" concept has the basis for our WCSAP (Wildcat! Sender Authentication Protocol) SMTP Level Filter. Since 2003 it has been a persistent and huge chuck of our total SMTP level filters around %60 for the CBV (Callback Verification). Logs are generated every night, http://www.winserver.com/SpamStats RFC 2821/5321 does provide an "opening" for validating the return path in section 3.3: 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. What we did was delay any checking for MAIL FROM: until the RCPT TO: is valid because we also found a HUGE failure with RCPT TO also around %60+. This was important to reduce all the DNS lookup with WCSAP when it validates the return path. So no checking is done until a RCPT TO: is valid. Other SPF sysops have carried on this delay SPF verification concept and I also got comments from Barricada people that it was a good idea to do this, especially the anti-relay checking where a random bad address is checked to see if the remote will accept always. That said, I don't advocate wide spread usage for a CBV (Call Back Verification) but the fact remains most of the time they are BAD from bad guys. Also, I don't think an EXTENSION for SMTP to do a "proper" CBV will work because the beauty of the current logic is that it addresses the legacy spoofers. Anything new will only address the NEW PEOPLE doing it wrong, it will not address the legacy SMTP clients and that is what CBV addresses. As it related to DKIM, well, it just goes to show it really has nothing to do with DKIM because it is a RFC 5322 technology. i.e. for us, DKIM will never trump SMTP level filtering by other means. At best, skip smtp checking, and do it at the DATA level or post SMTP acceptance, requires that the SMTP receiver stamp the spooled file with a Return-Path which was not always the case, but it is increasingly the case IMV. Any hoo, I do believe that when a sender does issue the MAIL FROM: it should be 100% correct at that point in time, not later because the SMTP assumption is that it is correct for the purposes of a BOUNCE potential. But I have heard arguments the the validity of the return path is only when the bounce is necessary. I don't agree with that. IMV, at the precise SMTP moment it is issued at MAIL FROM:, it *MUST* be valid at the time point. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html