Re: [spf-discuss] SPF, DKIM, and NIH

It is good to see a rebirth of SPF + DKIM integration discussions.

The issue, as it always been, is the complexity and the different ways 
and "philosophies" systems operate under.  Rest assured, your "Exim" 
installation is not the same as the next guys "ABC" product 
installation.   I can't say our "Wildcat!" system operates the same as 
others.  Quite often its a battle of the Old vs New School of 
thoughts.  As I always experience in multiple mail networks old and 
current, the contention were visible when there was Developers and 
Operators philosophical conflicts.  It is no different here.
So you need to come up with a common methodology that has sound 
engineering, most will follow either by standard or best practice.
SPF or rather the LMAP DOMAIN::IP assertion and methodology got 
immediate traction because it was simply to follow and more 
importantly fit into the framework with an easy implementation. It 
also came at a time where domain spoofing exploitations cause a HUGE 
back scatter problem leveraged by the infamous 2002/2003 SORBIG 
Accept/Bounce eVirus.  MARID and thus SPF was a result of this SORBIG 
problem highlight the major problem.
ADSP has/had that same potential for easy implementation and fit into 
the framework with a DOMAIN::POLICY assertion methodology.
One is 821 technology, the other is 822 technology. Only 
implementators can dictate an integrated solution - not a IETF 
solution, maybe a BCP document. But no dictation that both need to be 
used or one depend on the other.  Again, the vendor, local policy 
operator might love to do this, but the vendor/operator can't mandate 
to other vendors/operators thats how its should done.
Anyway, it would serve no justice attempting to summarize years of R&D 
on all this in one post, but to only say, keep it simple, come up with 
something that fits MOST implementations in plug and play fashion. And 
if possible, try to keep highly subjective ideas out of the solution.
--
Hector Santos, CTO
http://www.santronics.com


Michael Deutschmann wrote:

> On Mon, 12 Oct 2009, Scott Kitterman wrote:
> > This is where I think you go astray.  DKIM has no requirement for the "d"
> > domain and the body from domain to match.  So really all you are saying is
> DKIM doesn't.  DKIM/ADSP does, although signatures with "wrong" d= are
> ignored rather than considered errors -- a fact my proposal counts on.
>
> DKIM was built to allow for third-party signatures, but at present there is
> no standard way to indicate that signatures other than that for the From:
> domain *are required*.  That's what I want to fix.
>
> > check if the domain used in mail from has a DKIM key record?  If so, that's
> > a problem because you need to go to DATA to get the signature to find out
> > what the selector is.
> No, at MAIL FROM: time you check whether the SPF record has a flag
> indicating an envelope signing policy (such as my "fm=dkim" suggestion).
> If the flag is set, you know, before seeing the DATA yourself, that either
> the message will have a valid signature with d= matching the Return-path:,
> or it is forged.
>
> The test is more expensive than SPF, but when supported it is more accurate,
> since it is as immune as DKIM/ADSP to the forwarder problem.
>
>
> And remember, if SPF returns fail *and* you are sure the message is
> not a forward, you are still allowed to reject the message without ever
> looking at the DATA.
>
> ---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>




-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com