On 10/15/2017 11:52 PM, Grant Taylor wrote:
On 10/15/2017 07:39 PM, John Levine wrote:
Wow, you're the optimist.
I am, but I think that's independent of this.
If you tell me that you will only send email from given location(s)
and that I should treat everything from anywhere else as suspect,
that's exactly what I'm going to do.
I believe that the onus is on you to either adhere to what you say, or
change what you say to reflect your new sending location(s).
I believe in Taylor Mali's "policy about honesty and ass-‐kicking: if
you ask for it, then I have to let you have it."
Link - What Teachers Make
- https://taylormali.com/poems/what-teachers-make/
If you put "-ALL" in your SPF record, I'm going to reject messages
purportedly from you that fail your SPF record. ;-)
+1.
For failures, the SPF domain declaring an -ALL is expecting rejection
and if not, due to a receiver local policy, the SPF domain will|should
expect the accepted message to be separated from the target user's
main online mail in-box stream and/or POP3 mail stream which is
generally a single pickup channel, not one combined with normal+spam
folders. Don't presume IMAP is always users or Online only. POP3 is
still active.
See the RFC7208 security considerations section 11.7.
https://tools.ietf.org/html/rfc7208#section-11.7
11.7. Delivering Mail Producing a "Fail" Result
Operators that choose to deliver mail for which SPF produces a "fail"
result need to understand that they are admitting content that is
explicitly not authorized by the purported sender. While there are
known failure modes that can be considered "false negatives", the
distinct choice to admit those messages increases end-user exposure
to likely harm. This is especially true for domains belonging to
known good actors that are typically well-behaved; unauthorized mail
from those sources might well be subjected to much higher skepticism
and content analysis.
SPF does not, however, include the capacity to distinguish good
actors from bad ones, nor does it handle the concept of known actors
versus unknown ones. Those notions are out of scope for this
specification.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
