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