On Mon, May 15, 2017 at 11:02 AM, D'Arcy Cain <[email protected]> wrote: > 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.
I mean, you can, but there's this thing called forwarding, and there are good reasons to not rewrite the envelope sender when forwarding... and sometimes good reasons to do so. Brandon
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
