[vox] email stuff!

[Rick Moen]

Quoting Brian E. Lavender (brian at brie.com):

> Yay for dmarc! 

Comment below.

Date: Tue, 11 Jun 2019 23:24:04 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Don Dugger <n0ano at n0ano.com>
Subject: Re: Can you send email to comcast.net

Quoting Don Dugger (n0ano at n0ano.com):

> What the subject says.  I can't seem to send email to comcast.net
> addresses, I get a 421 (delayed) bounce message and then the email
> never goes through.

Yes I can.  A number of these are frequent correspondents of mine:

$ grep comcast .mutt.aliases
alias elizabeth "Elizabeth Sunde" <libeth1042 at comcast.net>
alias karljr "Karl Eikeberg" <kaeikeberg1 at comcast.net>
alias lyle "Lyle Johnson" <lyle.johnson at comcast.net>
alias nancy "Nancy Eikeberg" <nceikeberg at comcast.net>
alias paulc "Paul Carreras" <irishzin at comcast.net>
alias wells "Patty Wells" <orycon25chair at comcast.net>
$

> I have an SPF record but I've avoided DMARC and DKIM (I `really`
> don't want to be cryptographically signing every email I send)
> which could be the problem but it looks like you don't do DMARC
> or DKIM either.

I'm explictly avoiding DMARC/DKIM because I consider them badly botched
and therefore am declining to implement them.  (For example, DMARC badly
breaks mailing lists, requiring painful kludges to work around the
problem.)  Like you, I have SPF, and make sure my domains' SPF RRs are
very clear, simple, and unequivocal.

My linuxmafia.com.zone file:

;called as ORIGIN linuxmafia.com.
$TTL 86400
@       IN      SOA     ns1.linuxmafia.com.  rick.deirdre.net. (
                        2019032901              ; serial
                        7200                    ; refresh 2 hours
                        3600                    ; retry 1 hour
                        2419200                 ; expire 28 days
                        900                     ; negative TTL 15 mins
                        )
;
                IN      NS      ns1.linuxmafia.com.
                IN      NS      ns3.linuxmafia.com.
                IN      NS      ns6.linuxmafia.com.
                IN      NS      ns.primate.net.
                IN      NS      ns.tx.primate.net.
                IN      A       198.144.195.186
                IN      MX      10      null-mx.linuxmafia.com.
                IN      MX      20      linuxmafia.com.
                IN      MX      30      tarbaby.junkemailfilter.com.
                IN      TXT     "v=spf1 ip4:198.144.195.186 -all"
[...]

My unixmercenary.net.zone file is about the same.

:r! dig -t txt n0ano.com +short
"v=spf1 a mx a:cowluver.com -all"
"v=spf1 a mx a:doubleplus.biz -all"

Hmm, seems suspiciously complex.  Mine used to have 'a' and 'mx' in the
tokens, but then I realised that because all mail originates from my
main server IP 198.144.195.186, I could radically simplify and save
A-record lookups.  But you know what's right for your outbound-mail
situation.  Maybe?  Or maybe not?  Poke around some more:

:r! dig -t a n0ano.com +short
67.41.209.129

:r! dig -t mx n0ano.com +short
0 willie.n0ano.com.
:r! dig -t a willie.n0ano.com. +short
67.41.209.129

:r! dig -t a cowluver.com +short
67.41.209.129

:r! dig -t a doubleplus.biz +short
67.41.209.129

Er, I can't help noticing that 'a', 'mx', 'a:cowluver.com' and
'a:doubleplus.biz' all currently resolve to the same IP address.
So, unless the intention is to avoid needing to update the SPF RR
if one of the related four 'A' records change, it would seem that you've
written an overcomplicated SPF RR that requires four DNS forward
resolutions plus an MX-to-A resolution, i.e., five DNS operations, when
you could more simply stated the same situation as a single IP address,
thus zero additional DNS operations required.  Like this:

n0ano.com.    IN    TXT    "v=spf1 ip4:67.41.209.129 -all"

That _may_ suit your needs, or your needs may actually be more complex
than I'm aware (e.g., those A records may be subject to significant
change), in which case my suggestion may not be a good one.


Comcast's 421 Delivery Status Notification probably included
English-language text explaining what they think the issue is, possibly
including a Comcast URL for more information.  Check that.


Just to check your MTA IP reputation, I put your 67.41.209.129 IP into
http://multirbl.valli.org/ (but, important!, change the 'Test' pulldown
to 'DNSBL lookups' before hitting Send).

When I first used http://multirbl.valli.org/, I badly misinterpreted
what the colour red means, in results of a test run.  It doesn't mean
your IP failed a reputation test at that DNSBL; it means the test CGI
failed to reach that DNSBL in order to ask it to do a test.  The CGI
sometimes bellyflops and returns a sea of red.  Don't panic:  Just run
the CGI a second time.

After running the CGI twice, I got what appeared to be reasonable and
reliable results.  Out of 226 DNSBLs attempted:

221 returned 'not listed' (green) -- which means excellent reputation
  0 returned blacklisted (black)
  0 returned yellowlisted (yellow)
  0 returned whitelisted (white)
  0 returned neutrallisted (blue)
  5 failed (red)

One could not ask for a better result.  (It's common for a few of the 
226 DNSBLs to be unreachable at any given time, hence red.)  So, it's
highly, highly unlikely that Comcast considers your IP a spamhaus.


Also, I then turned to do a broader check of your DNS (and related mail
acceptance, see below) for errors, but decided to be lazy and use the
DNSreport CGI on https://tools.dnsstuff.com/ , entering 'n0ano.com'.
Note that he uses an HTTP cookie to limit how many times you can use the
tool without paying, so clear cookies or use a private browsing window
to circumvent that control.

The CGI is not perfect but it's good.  I've talked to the author about
his belief that domains need to have backup MXes, and he concedes my
point that the contrary view is very arguable.  For the record, the
two 'FAIL' results are serious, and could easily be your problem with
Comcast.

That is, the RFCs really _do_ require that mail-sending domains accept
inbound mail to both a postmaster@ and an abuse@ address, and yours
refuses that mail.  Many SMTP sites check for such RFC-compliance and
punish with a variety of suspicion-implementing practices mail-sending
domains that don't comply, because that's a useful proxy for spamhaus
mail.

You should fix that, ASAP.

Yes, I can already hear your objection:  'But those addresses will get
mostly spam!'  True.  And, personally, I do my best to reject at SMTP
time spam arriving for those, considering it unreasonable to interpret
the RFCs as requiring spam-acceptance at that or any other mailbox.

It's also in your interest to increase SOA EXPIRE to the
RFC1912-recommended range of 1209600 to 2419200.


I hope that helps.  Let me know how it works out!