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.
Now of course we all know that if I used "!all" in my SPF
record, this would break messages from my users who:
1 - ... are currently offsite but set their From: line to
my domain, then submit mail through another provider.
2 - ... post through a mailing list offsite which doesn't
munge "From:".
3 - ... send to recipients who in turn forward their mail
(without fancy workarounds) to a third site.
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.
Therefore, I don't think that SPF has a "registration problem".
It has plenty of other problems, but not that one. ;-)
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.
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 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!
What am I missing?
Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email protected] +1 514 848-2424 x2285
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
