On 5/5/2015 11:24 PM, Scott Kitterman wrote:
No. It's fundamentally different.
For SPF, the managers of an ADMD need to determine their authorized outbound
email architecture. That's in the hands of the administrators. For these
email list registration proposals it's the mailing list proclivities of every
single user.
Scott K
It is fundamentally the same problem both DMARC and SPF has and I
might even suggest, it may be even worst for SPF.
With SPF, users also have "proclivities" to roam around and send mail
from unknown, "unregistered" machines. I wouldn't say "every single
user" have the same behavior of being list members but most people do
travel, and may use different IP devices with POP3/IMAP/SMTP.
With SPF, you still have almost all the very large "public service"
domains such hotmail.com, yahoo.com, aol.com, msn.com, etc, who have
not yet figured out their "SPF network" in order to be very restrictive.
If any of these domains, all of a sudden, turned on the -ALL rejection
switch, oh my, we will see a tremendous amount of complaining as well.
For the domains that have locked it down with the hard fail, -ALL
policy, they have made a very strong public DNS statement about
limiting who can send mail on their behalf, just like Yahoo.com did
with DMARC who is now telling the world via their SPF and DMARC policies:
I don't know from where my yahoo.com are sending mail from,
but I want to tell you, they all must be signed exclusively
by yahoo.com
Yes, these are very much the same problem and I don't believe its
right to be demoting technically sound protocols for the same
"registration' problem that SPF still has with a long term prospect
for collecting the network of machines in order to be able to publish
restrictive policies.
We have two basic technical proposals.
The first one, the DNS CALL method, I view, as the absolutely
baseline, proof of concept method. It will work, we know it. Its
already in practice. Just put the data there and it will work if you
add the logic to your policy check. This follows RFC5585 DKIM Service
Overview guidelines.
The 2nd one, has the same 3rd party signer authorization purpose, but
has more work with required changed DKIM code. It uses an in-band
double signature method. It is theoretically less secure, but the
theory here is that the signer will have a basic idea of the list
domains to passively register via the message -- a unknown
registration problem, perhaps a little less because it seemingly
bypasses getting the DNS administrator and DNS network department
involved.
The proper engineering compromising solution SHOULD be to offer both.
The idea of having a SAM or Signature Authorization Method or as Doug
calls it "Specific Advisory Method" tag in DMARC, is a sound technical
IETF way of resolving this problem that is agnostic to all parties.
sam=tpa use a third party DNS lookup method
sam=levine use levine's double signature idea
Personally, I would use the DNS method only because its cheaper to get
to this planet, but if we really think the levine bypass will work as
well, add it too.
I am just saying lets not lump everyone into the same DNS
publishing/registration problem the hotmail.com, yahoo.com, aol.com,
msn.com domains have. Others will not.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
