spf-discuss at winserver
Oct 16, 2009, 6:06 PM
Post #55 of 63
(2086 views)
Permalink
|
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>
-------------------------------------------
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
|
