Re: [ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
On Wed, Dec 8, 2010 at 9:53 PM, Dave CROCKER d...@dcrocker.net wrote: On 12/8/2010 8:36 PM, 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. Right. No one will ever again be allowed to drop mail packages into a postal slot, because each piece of mail is going to have to have its return address verified... (exercise to the reader: why do I have verified in quotation marks?) So, as you note, the fun orientation towards security theatre makes this announcement no surprise, but serious enforcement of it will... We don't validate the contents of all shipping containers coming into the US, but we /are/ going to verify the return address of all postal mail. Sounds like just the right priorities to me... The two of you made my night, no, week, no Year!!! Mark, sx6un-fc...@qmda.emu.st? Did you forge that? (to lazy to look at headers tonight) -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
On 12/8/2010 8:36 PM, 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. Right. No one will ever again be allowed to drop mail packages into a postal slot, because each piece of mail is going to have to have its return address verified... (exercise to the reader: why do I have verified in quotation marks?) So, as you note, the fun orientation towards security theatre makes this announcement no surprise, but serious enforcement of it will... We don't validate the contents of all shipping containers coming into the US, but we /are/ going to verify the return address of all postal mail. Sounds like just the right priorities to me... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?
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
