From daniel.thatcher at gmail.com  Tue Jun 11 09:51:28 2019
From: daniel.thatcher at gmail.com (Timothy D Thatcher)
Date: Tue, 11 Jun 2019 09:51:28 -0700
Subject: [vox] email stuff!
Message-ID: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>

Well, I've in theory implemented SPF, DKIM, and DMARC with lugod's
mail server/DNS. Consider this a test message to see if mail delivery
still works! If so it should make some larger mail providers happy, I
hope - maybe we'll even stop getting blacklisted for spam that we're
not sending. :V

Tim

From brian at brie.com  Tue Jun 11 19:33:37 2019
From: brian at brie.com (Brian E. Lavender)
Date: Tue, 11 Jun 2019 19:33:37 -0700
Subject: [vox] email stuff!
In-Reply-To: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>
References: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>
Message-ID: <20190612023336.xcrdg2tbaijtzlyu@brie.com>

Yay for dmarc! that's a negative on dkim. :) 

Maybe this one will help.
https://wiki.debian.org/opendkim

brian

On Tue, Jun 11, 2019 at 09:51:28AM -0700, Timothy D Thatcher wrote:
> Well, I've in theory implemented SPF, DKIM, and DMARC with lugod's
> mail server/DNS. Consider this a test message to see if mail delivery
> still works! If so it should make some larger mail providers happy, I
> hope - maybe we'll even stop getting blacklisted for spam that we're
> not sending. :V
> 
> Tim
> _______________________________________________
> vox mailing list
> vox at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox

-- 
Brian Lavender
http://www.brie.com/brian/

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."

Professor C. A. R. Hoare
The 1980 Turing award lecture
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lugod.org/pipermail/vox/attachments/20190611/db194f34/attachment.sig>

From daniel.thatcher at gmail.com  Tue Jun 11 20:49:21 2019
From: daniel.thatcher at gmail.com (Timothy D Thatcher)
Date: Tue, 11 Jun 2019 20:49:21 -0700
Subject: [vox] email stuff!
In-Reply-To: <20190612023336.xcrdg2tbaijtzlyu@brie.com>
References: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>
 <20190612023336.xcrdg2tbaijtzlyu@brie.com>
Message-ID: <CAGubMV8jkQHyJEnmjEnf2_823DqwkWpVme+YrHt3=m8YgfLuqg@mail.gmail.com>

I think I got it this time. :D

Tim

On Tue, Jun 11, 2019 at 7:33 PM Brian E. Lavender <brian at brie.com> wrote:
>
> Yay for dmarc! that's a negative on dkim. :)
>
> Maybe this one will help.
> https://wiki.debian.org/opendkim
>
> brian
>
> On Tue, Jun 11, 2019 at 09:51:28AM -0700, Timothy D Thatcher wrote:
> > Well, I've in theory implemented SPF, DKIM, and DMARC with lugod's
> > mail server/DNS. Consider this a test message to see if mail delivery
> > still works! If so it should make some larger mail providers happy, I
> > hope - maybe we'll even stop getting blacklisted for spam that we're
> > not sending. :V
> >
> > Tim
> > _______________________________________________
> > vox mailing list
> > vox at lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox
>
> --
> Brian Lavender
> http://www.brie.com/brian/
>
> "There are two ways of constructing a software design. One way is to
> make it so simple that there are obviously no deficiencies. And the other
> way is to make it so complicated that there are no obvious deficiencies."
>
> Professor C. A. R. Hoare
> The 1980 Turing award lecture
> _______________________________________________
> vox mailing list
> vox at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox

From brian at brie.com  Tue Jun 11 21:50:59 2019
From: brian at brie.com (Brian E. Lavender)
Date: Tue, 11 Jun 2019 21:50:59 -0700
Subject: [vox] dkim
Message-ID: <20190612045059.b35jyanq6klyksbk@brie.com>

seeing if i see a dkim sig

-- 
Brian Lavender
http://www.brie.com/brian/

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."

Professor C. A. R. Hoare
The 1980 Turing award lecture

From rick at linuxmafia.com  Tue Jun 11 23:37:35 2019
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 11 Jun 2019 23:37:35 -0700
Subject: [vox] email stuff!
In-Reply-To: <20190612023336.xcrdg2tbaijtzlyu@brie.com>
References: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>
 <20190612023336.xcrdg2tbaijtzlyu@brie.com>
Message-ID: <20190612063735.GA5228@linuxmafia.com>

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!



From rick at linuxmafia.com  Wed Jun 12 00:46:37 2019
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 12 Jun 2019 00:46:37 -0700
Subject: [vox] email stuff!
In-Reply-To: <20190612063735.GA5228@linuxmafia.com>
References: <CAGubMV-2Q0AcqKpzz_9Gyfb7qAWOJEM5yibpayscT_BQTXmkrw@mail.gmail.com>
 <20190612023336.xcrdg2tbaijtzlyu@brie.com>
 <20190612063735.GA5228@linuxmafia.com>
Message-ID: <20190612074637.GB5228@linuxmafia.com>

Since I did that for my friend Don concerning his n0ano.com domain,
let's do some of the same for LUGOD.

Checking the DNSreport CGI at tools.dnsstuff.com for 'lugod.org':

1.  Domain sends mail yet (according to the CGI) refuses mail to
postmaster@ and abuse@

postmaster@ requirement:   RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1 
abuse@ requirement:  RFC2142 Section 2

2.  Looks like there are some problems with glue records in the parent
.org zone -- but I see that LUGOD has outsourced its DNS to TierrNet
d/b/a DomainDiscover, my old registrar from many years ago.  Yeah, they
always had problems with that, referring to ns1.tierra.net in some
places and ns1.domaindiscover.com in other places.  LUGOD isn't going to
be able to get them to fix that -- unless you make the decision to stop
outsourcing and use LUGOD-specified nameservers.

3.  Likewise, Domain Discover are gladly willing to reveal to the entire
Internet that they run specifically version 4.0.7 of PowerDNS.  I like
PowerDNS for large sites, but I sure wouldn't enable version.bind
queries for anyone on the Internet, like that.  (This is obviously also
not under LUGOD's control except by using non-Domain Discover
authoritative nameservers.

4.  Their SOA EXPIRE is, like Don Dugger's, much shorter than is
RFC-recommended.  Dunno, are you able to edit the SOA?  If so, it really
ought to be raised to the bracket 1209600 to 2419200 seconds.



Moving on fron DNSreport:

Your SPF RR is "v=spf1 a mx -all" .  Let's see what those two tokens point to:

:r! dig -t a lugod.org +short
138.197.203.91

:r! dig -t mx lugod.org +short
10 www.lugod.org.
:r! dig -t a www.lugod.org. +short
138.197.203.91

So, as with Don Dugger's SFP RR for n0ano.com, this is grossly
inefficient, being basically a complicated way of saying IP
138.197.203.91, except with pointless resolution of two A records and an
MX record, just so receiving MTAs can query that information.  It would
be much more straightforward to just say

lugod.org.  IN  TXT  "v=spf1 ip4:138.197.203.91 -all" 

...thus requiring a total of zero extra DNS resolutions to use the
published SPF information, instead of three pointless extra DNS
resolutions.