Ok, so off-list I've been having this conversation with about 3 other
QMT users about SPF & QMT. Throughout the discussion, we've talked
about SPF handling of both INBOUND mail (the
/var/qmail/control/spfbehavior setting which controls how we process
other people's SPF records) -and- OUTBOUND mail (the DNS SPF records
that tell other people how to handle OUR SPF records).
It will come as no surprise to most, but I have some opinions on these
-- opinions that it was suggested that I share with this group for
discussion;
1) Inbound SPF Mail Processing
- Although admittedly reported by others, I have very seldom had
issues with QMT processing of SPF records - and when I did, it was
usually a DNS error, not a processing one.
Still, I agree with Eric that it should be more of a simscan or
spamdyke setting than a QMail setting. Be that as it may, I still trust
and rely on SPF for minimal SPAM control.
NOTE: If simscan and/or spamdyke were to take on SPF, they should
also include the DMARC specs as well.
- Because I haven't had the problems others have reported (maybe
because I use BIND9?), I use a value of *3 (yes, THREE)* in the
*/var/qmail/control/spfbehavior* file
This means that, if a sender has an SPF record and it says to
/hard-fail/ unless the rules are met, then by golly, I reject
non-compliant messages!
However, many (/perhaps even most/?) SPF records are published with
a SOFT-FAIL option (~all), so those soft-fails are still permitted through
Domains that have NO SPF record, invalid SPF records, or whose DNS
lookups fail are also allowed
2) Outbound SPF Mail Processing (a lot more discussion on this one, I
suppose)
- There are plenty of HOWTO's for this one, but *I* prefer to do the
following [using YOUR domain(s) instead of domain.com]:
a) Create a TXT record for *spf.domain.com *(and, if supported, a
duplicate SPF record) that reads
"v=spf1 ip4:x.x.x.x *?all*"
Repeating the ip4 parts for each IP address that your legitimate
MTAs may reside
While this seems like an EXTRA step, it will help greatly if,
later on, you decide to host multiple domains on your server.
Why? because if you make each domain a stand-alone SPF record,
then when your ISP forces you to change your IP address, you have to
make the change in each and every one of your hosted domains' SPF
records.... with the spf.domain.com TXT (and/or SPF) record, you can
"include" the spf record from your domain to their domain and change
multiple domains simultaneously.
Next, what's with the *?all *at the end? This creates a "neutral"
result for anything that doesn't match the rules so far -- this means
that if there is a problem with the include, no pass/fail is set at all.
This way, the domain in which you use the include is free to use
additional includes and to set their own fail policy (~all or -all).
b) So, as alluded to above, the next step is to create TXT (and SPF)
records for your actual domain(s) that show:
"v=spf1 *include:spf.domain.com -all*"
The include part should make sense now -- but many people question
why I use -all (instead of ~all).... and the answer for me is simple...
I know what I'm doing! LOL! The ~all setting is SUPPOSED to be used
while you're "testing" SPF settings. With the ~all, a mail server (MTA)
receiving a message from my domain is supposed to note that there is an
error, but let the message pass (unless configured to fail on soft-fail
codes as well)... that's essentially not even using SPF! With the -all,
I'm telling the likes of Yahoo!, Gmail, etc. that if it says its from my
domain, and it isn't from one of MY servers, then kick it back -- it
must be bogus.
As some of you know, I host quite a bit of email (enough that I
now have 3 separate mail servers, each with their own domain lists!)...
some of the clients on those mail servers pay extra for MessageLabs
(Symantec) to do extra SPAM and AV checking (more than simscan &
spamdyke)... in doing so, all I have to do for those domains is use the
appropriate "include:spf.messagelabs.com" type statement and I can
redirect their mail to the appropriate (or receive their mail from the
appropriate) set of servers. In these cases, their SPF records look like:
"v=spf1 *include:spf.it4soho.com include:spf.messagelabs.com -all*"
c) The final step takes me back to DNS again... and the "newbie" to
the SPAM fighting arcade: DMARC (see DMARC.org)
NOTE: Because DKIM in QMT is essentially "break prone" (as-in it
often fails -- especially for mail from other QMT hosts -- even when all
outside tests say things are good), I choose to implement DKIM in a
TESTING mode. This isn't important here, except to explain why DKIM is
noted in my DMARC record the way that it is....
ASIDE: If anyone wants to discuss the merits, demerits of DKIM,
I'm happy to do so -- I just found that it was broken too often, so I
removed it from my configs
DMARC is relatively new (since 2012), but purports to try to tell
mail recipients just what kind of message authentication is being used
by the sending domain, AND to provide a user-identified method of
reporting back issues and/or errors.
I'm going to show my own DMARC record, then explain it below:
"v=DMARC1; p=reject; aspf=s; adkim=r;
rua=mailto:it4s...@it4soho.com; ruf=mailto:it4s...@it4soho.com";
Like SPF, DMARC is implemented with DNS TXT records:
- v=DAMRC1 means this is a version 1 format
- p=reject means that the policy for failed tests should be to
reject them (other options include quarantine & none)
- aspf=s means I recommend using SPF in a strict mode (the
alternative is a relaxed mode)
- adkim=r means I recommend using DKIM in a relaxed mode (this
is the default, so I could have not included this entry)
- rua=mailto:it4s...@it4soho.com means that reports (non-failure
feedback) should be sent to it4s...@it4soho.com
- ruf=mailto:it4s...@it4soho.com means that failure reports
(like detected SPAM) should be sent to it4s...@it4soho.com
Now QMT doesn't yet support DMARC -- but I would assume that spamdyke
eventually will... in any case, it's the recipient that has to implement
it, and for now I would like to receive those error reports if they're
available!
Open to discussing this with the rest of the group -- security (and SPAM
control) are both topics we should banter around periodically!
Ciao!
Dan McAllister
IT4SOHO
QMT DNS/Mirror Admin
--
PLEASE TAKE NOTE OF OUR NEW ADDRESS
===================================
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
