Emailserver for betaprogram@letsencrypt.org


#1

I just noticed the the email server sending the beta invites does not have a PTR record and so was rejected by my mail server. Seeing that checking for PTR records is quite common this should probably be fixed. Also it does not use STARTTLS which it should.

Out: 220 mail.nuxio.de ESMTP Postfix
In: EHLO mail.letsencrypt.org
Out: 250-mail.nuxio.de
Out: 250-PIPELINING
Out: 250-SIZE 104857600
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:betaprogram@letsencrypt.org SIZE=11266
Out: 250 2.1.0 Ok
In: RCPT TO:XXXX@XXXX.de ORCPT=rfc822;XXXX@XXXX.de
Out: 450 4.7.1 Client host rejected: cannot find your hostname,
[66.133.109.36]
In: DATA
Out: 554 5.5.1 Error: no valid recipients
In: RSET
Out: 250 2.0.0 Ok
In: QUIT
Out: 221 2.0.0 Bye


#2

Hm would be interesting how many beta invite mail have been blocked.


#3

PTR record may even be a requirement to be RFC compliant. At least I thought it was. Though I could be wrong.


#4

Ugh. TLS is turned on now, but getting the PTR record is going to take some time from upstream. I suppose getting DKIM and SPF right isn’t so useful if some mailservers reject based on a missing PTR record.

Received: from mail.letsencrypt.org ([66.133.109.36])
    by mx.google.com with ESMTPS id sn6si2173922oeb.63.2015.10.29.13.41.27
    for <my-email-address>
    (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Thu, 29 Oct 2015 13:41:27 -0700 (PDT)

I can only apologize; the ops team shouldn’t have trusted me to provide the configuration for the email server.


#5

I could help fix this…

I think you need more than a PTR because mail.letsencrypt.org is pointing to Google.

cp@earth:~$ host letsencrypt.org
letsencrypt.org has address 23.42.91.68
letsencrypt.org has IPv6 address 2001:418:141b:19b::2a1f
letsencrypt.org has IPv6 address 2001:418:141b:197::2a1f
letsencrypt.org mail is handled by 10 aspmx3.googlemail.com.
letsencrypt.org mail is handled by 1 aspmx.l.google.com.
letsencrypt.org mail is handled by 5 alt1.aspmx.l.google.com.
letsencrypt.org mail is handled by 5 alt2.aspmx.l.google.com.
letsencrypt.org mail is handled by 10 aspmx2.googlemail.com.
You have new mail in /var/mail/cp
cp@earth:~$ host mail.letsencrypt.org
mail.letsencrypt.org is an alias for ghs.googlehosted.com.
ghs.googlehosted.com has address 74.125.22.121
ghs.googlehosted.com has IPv6 address 2607:f8b0:400d:c06::79
cp@earth:~$ host 66.133.109.36
Host 36.109.133.66.in-addr.arpa not found: 2(SERVFAIL)

My advise is add a hostname, a PTR, and reconfigure the mail server for the new name. I also like to have the forward and reverse DNS resolution match. It might not be a bad idea to add DKIM and SPF while you are at it since you need to contact AKAM.net for your DNS changes (if you aren’t running your own hidden master)… I like to run a hidden master DNS server.


#6

I’m told we’re sending the next batch from outbound1.letsencrypt.org, but the PTR reverse records will take time.

DKIM and SPF are already being applied (that, I did!). At least, I see them on test emails and Google marks them as passing.

Received: from outbound1.letsencrypt.org ([66.133.109.36])
    by mx.google.com with ESMTPS id e202si2230336oic.128.2015.10.29.14.08.59
    for <my-email-address>
    (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Thu, 29 Oct 2015 14:08:59 -0700 (PDT)

#7

PTR records are now set for the mail servers; they’re propagating out currently.


#8

I suggest to also add a “Date:” header to your mails. At least our invitation from 2015/10/28 didn’t have one.
(SpamAssassin by default gives 1.4 points for missing Date header)


#9

Got it. The next batch will have it. Thanks!


#10

well but that would be a problem for those with shared hosting…

or those who dont have full control over their IP records (home-hosting)


#11

Only if they are trying to run an SMTP server on such a service.


#12

yeah I know and if you for example have a domain and a raspi, why pay for a hosted server?


#13

Because of dynamic DNS, hardware, network connectivity, … :wink:


#14

well dyndns isnt really a problem, there are enough providers for that one. well the raspi 1b isnt the best one but when I get like 5 mails a week there should be no problem regarding that one, and well connectivity, that is a point…


#15

If you want to host a mail server, don’t use a dynamic IP. I’ll be not accepted by most mail servers.


#16

If you’re going to run an smtp server learn the requirements and meet them. Otherwise you’re just asking for rejected mail.


#17

but what’s wrong with using a dynamic IP, why is that a requirement?

it’s the same junk that it’s forbidden for normal ppl to get an EV and the same being required for .onion drives that one even further


#18

Dynamic or static IP address itself doesn’t directly matter. It’s that services utilizing dynamic ip addresses don’t typical meet other requirements. So once again if you’re going to operate an SMTP server learn the requirements or expect to experience rejected mail.


#19

well at least an SPF is already in place.


#20

Which is nice. And I require it for my personal mail system. But SPF is not an official requirement though I advocate it. A correct PTR record is an RFC requirement though I believe. Good luck getting that with a dynamic ip service. Many, maybe even most SMTP servers will reject mail if there is not a proper PTR DNS record.