On Fri, May 16, 2014 at 1:43 PM, Steve VanDevender <
[email protected]> wrote:

> David Lang writes:
>  > remember SPF records and how they were supposed to completely
>  > eliminate spam?  and how they had similar problems with mailing lists
>  > and have now faded a bit, only to be replaced by this next attempt.
>
> Many of the proponents of SPF, and now DMARC, are these large providers
> who have essentially captive user bases and a level of central control
> where they can require them to use only their systems to send mail using
> their domains.  If you're an organization that doesn't have that level
> of centralization (such as, in my case, a university) then SPF or DMARC
> are much more problematic.  You can't publish a restrictive SPF record
> for the domain as a whole because there are too many different
> subdomains operating essentially independently of any central IT
> organization, and publishing a non-restrictive SPF record is kind of
> pointless.


We have been mucking with our SPF record a bit lately, because we have
outsourced our mail to both Google & Microsoft. Between the two of them,
they overrun the max 10 DNS lookups for an SPF record, so we were using
+all, which upset some people. We have a sad hack around it for right now,
but we still can't do restrictive than ?all (neutral).

I'm not actually that concerned about subdomains, our top level domain SPF
record only applies to mail using that top level domain, subdomains need to
have their own. We're now looking at DKIM, because we can sign everything
on our Google Apps domain, and everything that comes through our own
mail servers. We just can't sign most things that go through Office 365 yet.
And I see no way we'd ever be able to publish a DMARC record of reject. We
have Central IT groups using Constant Contact, we have a contracted alert
notification system that uses outside servers that considers their hosts to
be
a business secret(!), and we have random other silly things going on.

One of the things that is helping me when I'm explaining this is that it is
an
anti-spoofing tactic, not an anti-spam tactic. It is supposed to give a
boost
to signed mail / SPF'd hosts, not to be used for spam marking unless we
publish a DMARC record telling people to reject non-signed mail. The fact
that they're all just part of an arms race is mostly something I'm only
likely to
admit to a select few.

-Tracy
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to