On 5/8/2015 1:29 PM, Anne Bennett wrote:
Murray S. Kucherawy writes (with respect to ATPS if I got this right):
There's still that pesky registration problem to address.
Hector Santos writes:
Separate issue. SPF would not be here if you used this same criteria.
None of the big domains you are concern about have hard fails for SPF
for the same reason -- it can not "register" their SPF network of
possible users. Same problem.
I'm not convinced that it's the same problem at all.
In the case of SPF, I am (supposed to be!) in control of
and knowledgeable about which IP addresses are used by my
outgoing mail relays, including any third parties I might hire
to send out bulk mail on my behalf. Their registration by me
into my own DNS is trivial.
How about your roaming users? How about when users use other MSA
sites? If you have such a mail network among your domain, then for
the most part, the domain is restricted to relaxed policies. It
can't use hard policies.
Please note, as an early explorer, I didn't believe it was a problem
for SPF, nor do I believe its a problem for ATPS-rev04. SPF suffered
through the same basic "scale" and lack of path independence
arguments. "SPF was not path independent. It didn't scale." DKIM was
suppose to be the alternative as a path independent solution -- that
was the marketing behind it.
Now of course we all know that if I used "!all" in my SPF
record, this would break messages from my users who:
Do you mean "-ALL" hardfail policy?
1 - ... are currently offsite but set their From: line to
my domain, then submit mail through another provider.
Roaming user. :)
2 - ... post through a mailing list offsite which doesn't
munge "From:".
5322.From is not SPF related. You mean the 5321.MailFrom?
3 - ... send to recipients who in turn forward their mail
(without fancy workarounds) to a third site.
A simple relay, sure, SPF has that problem you will only see for -ALL
policies.
I don't think that anyone would suggest that the correct fix
for any of the situations above would be to add the relevant
IP addresses (of my offsite user's ISP's mail relay, of the
mail relays of all the mailing lists to which my users might
post, or of my users' recipients' "forwarding" mail relay)
to my SPF record.
I don't think anyone has suggested that. That is the domain's business
and it may also mean the domain is not a candidate for strong policies.
That is what surprised everyone when Yahoo.com flipped the rejection
switch. Its a long time public service domain with a wide network of
users, many roaming around. But the market is changing with more
centralization and domains wishing to finally clean up their aged and
spam-polluted domains.
Therefore, I don't think that SPF has a "registration problem".
It has plenty of other problems, but not that one. ;-)
To me, it is pretty much deja vu. :) I didn't have the problem as
most private, corporations, non-public service domains do not have
this problem. Only the public service domains have a bigger issue
with it. The corporate Microsoft.com domain can do a -ALL but can not
use a hard fail for outlook.com, hotmail.com and msn.com public
service domains.
Note again, I was not one to agree it was a problem for SPF as I don't
believe it is a problem for ATPS-rev04. But the same/similar issues
were raised. DKIM was argued as a better solution because it didn't
have the path independent problem. That was a flawed idea. They
both had mail path problems once you have a DKIM policy layer.
But if I understand correctly, it's being suggested that for
various proposals made here to work, either the sender's mail
system or the final receiver's mail system would have to become
aware of all of the "legitimate" (definition purposely left
out!) mailing lists to which its users subscribe.
To me, *that* is a registration problem.
Sure, but its a typical one and IMO, generally considered as an
implementation issue, more related to the business itself. You can
argue that its a barrier to adoption too, but its not something that
preempts protocol designs. APTS follows a standard client/server
negotiated Lookup methodology/solution that SPF, DMARC currently
enjoys as DNS-based applications. We are trying to fit in another
lookup or make it piggy back off the existing lookups to minimize the
overhead.
I believe that some people have claimed that this problem is
easily overcome (or perhaps "worked around" would be a better
expression) by examining mail headers and gathering statistics,
and this may well be the case, but addressing the problem in
this way will always depend on heuristics, just like any other
anti-spam method.
I agree. This is why it is a separate implementation issue. We are
looking for a deterministic protocol solution. The lack of not
having the "registration" in place first should not stop one from
"checking" to see if it exist. If this becomes wasteful with no
payoff, we can later deprecate it, turn it off. We desire a short
term adoption, adaptation, migration, etc, but it can be long term
too. Just considered, all this started around 2003 and we are still
fussing with it.
I cannot see how it would approach a reliable pass/fail result,
which I've been told is what DMARC is all about: don't make the
users have to decide anything! Handle it all before delivery!
Yes, deterministic, system level, no mail acceptance at SMTP, a 55x
return code. This can be also a SMTP accept/discard mode of operation
(250 and this discard it) or possibly the accept/quarantine mode of
operation which keeps it from the user's main in-box, but he can still
see it in a spam folder.
What am I missing?
Nothing. :)
You appear to have roaming user problems. You can't use a hard SPF
policy because you can't register all these users in how they send the
mail. Therefore, you have a more open, public, relaxed policy.
Millions of domains have more control and use a -ALL policy. They do
not expect their users from using their domains in public unknown ways.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
