Email Authentication (SPF)

Tough call on this one. I mind a fairly large mail system and I doubt that we would ever want to move to using DKIM as a ‘reject’ ruleset ( I’m more in the Yahoo-Cisco DKIM vs. Microsoft SPF camp, but all protocols of this nature are an improvement ).

I think there are some vendors out there that provide exceedingly good reputation blacklists — but who wants to wager that that one critical client’s email just happens to run afoul of the filter?

As such I think the most common implementation will be rulesets which respond to the level of failure by injecting an X-header, altering the subject or setting some other flag. Based on that flag big box mail architecture systems ( notes, exchange ) can alter the display to signify the level of failure.

Deciding to write a local rule to do a deletion should be up to the user.

I think that may be a good rule of mail systems administration in large organizations: Only users have the power to write autodelete rules.

The issue here isn’t Google’s, but rather Paypal’s – they publish an SPF record that’s weeny. Instead of declaring that they are sure that they are publishing all their potential mail relays and using a “-all” at the end of the SPF record, they use a “~all”, which is the soft failure. Google is doing the “right” thing per the SPF standard and not failing for this, because Paypal said they weren’t sure.

So, the real question is, when will PayPal, not Google, bite the bullet and change their SPF record to be certain.

Cement Head

I would suggest that a parse friendly syntax be used in the header line, that way I can use a rule in a brain dead e-mail client to redirect such messages into a suspect mail folder.

I have always favored spam filtering to simply flag a message with a header, than drop a message from reaching me. I see way too many false positives getting flagged as spam to trust a filter deleting messages without my review.

Exo