ietf-dkim
[Top] [All Lists]

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

2010-12-08 22:05:04

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

<Prev in Thread] Current Thread [Next in Thread>