On 2017-05-15 01:20 PM, Ken O'Driscoll via mailop wrote:
On Mon, 2017-05-15 at 12:34 -0400, D'Arcy Cain wrote:
[...snip...]
Are admins getting dumber or is the software (py-policyd in our case)
getting tougher?
You'd be surprised how many people who would identify as being technical or
worse, mail admins, still don't fully understand how SPF works. That
I would not be surprised at all. After thirty five years in various
areas of the computer industry I know exactly what to expect from the
"experts."
What do others think is best practice? Should we treat broken SPF
records as if there was no record and just not check the sending server?
This approach is taken by many mailbox providers. I don't think treating an
invalid SPF as the equivalent of none being present is a controversial
position anymore.
Yah, I already changed this while waiting for this discussion. Looks
like it should be permanent. Maybe I can add something to the message
to let users know that the sender is suspicious. Probably something in
the headers that can be examined by Spamassassin and add points. I
would do the same thing for broken records as well as non-existent ones.
I have an ISP client with the same challenge. They don't accept email from
sources not listed in the SPF (if present). If someone opens a ticket they
I hope that bouncing messages from servers not listed in a valid SPF
record isn't controversial.
use a 24h white-list which lets their user receive the mail and gives the
sender time to resolve their SPF. It's worked for the last few years
without issue.
Sounds like manual labour.
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:[email protected]
VoIP: sip:[email protected]
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
