[BCLUG] Interesting email about domain expiring - SPF vs SPAM question

[Rick Moen]

Quoting BCLUG (admin at bclug.ca):

> I got an interesting email today saying this domain was to expire today.

Am inferring "this domain" = bclug.ca .

> Since I just had a legit message from a utility provider that I'd
> missed a payment, my first thought was, "Oh no, not again."
> 
> But it was fake.
> 
> Where it gets interesting is the message was sent through the email
> server for this domain - the message ID is in the mail.log file.

Hold that thought.  By "through", you probably mean that the "From:" 
header forged your domain, right?  You could tell by looking at the 
full headers (display full headers, which is something done differently
in each different mail reader) and examining the Received: headers.

> Looking further, the SPF/TXT records for the domain all end with "~all".

Checking.

:r! dig -t txt bclug.ca +short
"v=spf1 +a +mx +a:lists.bclug.ca +ip4:199.212.143.222 +a:69.172.190.161  -all"

Late thought:  Presumably this is after you changed ~ to -.

The SPF RR for domain bclug.ca (now) has "-all", which (from memory) means
"consider this information definitive enough to conclusively reject
forgeries, and please do so".  Or, quoting the RFC:

  Only allow mail that matches one of the parameters (IPv4, MX, etc) in
  the record

In contrast, ~all is "softfail".  Quoting the RFC:

  Allow mail whether or not it matches the parameters in the record

...in other words, the receiving MTA might wish to consider the fail
among other factors, but is advised that the information is not
definitive.

For completeness, ?all is "neutral".  RFC says:

  No policy statement

...in other word, "We're so far just messing around.  Please disregard."




> While the server is doing SPF policy checking, this message still
> got through.
> 
> Does it sound like changing "~all" to "-all" would have prevented
> this message?

I think so?  Except there are syntax problems with even your revised SPF
RR, which I'll get to soon..

If you are certain you can positively declare to the public (in your
auth. DNS) the _only_ IP locations that should be deemed authentic
originators of your domain's outgoing SMTP, then it is strongly in your
interest to do so, in an unequivically stated "-all" TXT reference
record -- in preference to the inherently equivocal "~all" variety.

I do so (for my two domains).

:r! dig -t txt linuxmafia.com. +short
"v=spf1 ip4:96.95.217.99 -all"

:r! dig -t txt unixmercenary.net. +short
"v=spf1 a mx -all"

Please note that because SPF observance is not universal, forgery of my
domains still can occur.  The only difference my SPF RRs make is that
_if_ receiving SMTP hosts validate arriving mail for SPF observance,
_then_ they will reject all forgeries of my domains' mail.

> I've done that already, but would appreciate any advice on if it was
> The Right Move™ or useless.

I consider a strongly asserted SPF record A Good Thing.


Let's get to the syntax problems in

"v=spf1 +a +mx +a:lists.bclug.ca +ip4:199.212.143.222 +a:69.172.190.161
-all"  :

First problem:  The syntax of each and every object in there is wrong, 
because there's not supposed to be a "+" on any of them.  Field guide
to syntax (one of many):
https://support.google.com/a/answer/10683907

Second problem:  Aside from the +, the "a:lists.bclug.ca" is valid
syntax (will become valid once you remove the +).  But, seems to me, 
"a:lists.bclug.ca" is redundant to "ip4:199.212.143.222" -- because 
that's where the a record resolves to.

:r! dig -t a lists.bclug.ca +short
199.212.143.222

So, I'd say, lose "a:lists.bclug.ca", because all you're doing is making
SMTP servers do pointless additional DNS lookups, just to process your
SPF declarations.

Third problem:  "a" (which you wrote as "+a") is redundant to
"ip4:199.212.143.222":

:r! dig -t a bclug.ca +short
69.172.190.161

So, I'd say, lost "a", too.

That leaves "mx" (rendered here incorrectly as "+mx":  Where are your
MXes?  Let's check:

:r! dig -t mx bclug.ca. +short
10 lists.bclug.ca.
20 mail.bclug.ca.

:r! dig -t a mail.bclug.ca. +short
199.212.143.222

So, "mx" resolves to FQDNs lists.bclug.ca and mail.bclug.ca, which 
in turn resolve to IPs 199.212.143.222 and, um, 199.212.143.222 again.

It's not entirely clear to me why you declare the same IP twice as both 
higher-priority and lower-priority MX.  However, that point aside, you 
already have "ip4:199.212.143.222" in the SPF RR, so it seems to me
that "mx" is redundant -- and, again, merely requires consulting hosts
to do pointless DNS resolution.

Revised _candidate_ SPF RR for you:

bclug.org. IN TXT "v=spf1 ip4:199.212.143.222 a:69.172.190.161 -all"

Important:  There might be reasons why you want to add something else, 
e.g., adding "a" or "mx" might be justifiable in the sense of making
your SPF declarations remain accurate if you changed your MX DNS records
but forgot to change the IPs in the SPF RR.  Only you can decide how
complex you _need_ your SPF RR to be.  It should be what meets your
needs.  All I can say is that it _appears_ to me that the present
complexity doesn't serve a purpose I think you value, and doesn't
justify the many extra lookups imposed.

Hope that helps.


Bonus link:
http://linuxmafia.com/pipermail/conspire/2022-August/012144.html
(in which I chew out a grifter, and talk more about SPF and DMARC).