Subject: [ietf-dkim] Are arbitrary From addresses in the physical world following DKIM?

From: "Mark Delany" <[email-masked]>
Date: 8 Dec 2010 17:36:04 -0800

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 08 Dec 2010 21:53:10 -0500

> 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

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Dec 2010 22:27:46 -0500

> somewhat amusing in the DKIM context.

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

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 10 Dec 2010 23:10:16 -0500

> Sounds like just the right priorities to me...

The two of you made my night, no, week, no Year!!!

Mark, [email-masked]? Did you forge that? (to lazy to look at
headers tonight)

-- 
Jeff Macdonald
Ayer, MA