Hi Guys,
Firstly, my apologies to Tim, Slavek, Michele and Francois as I sent them a direct email regarding this problem because I thought the mailing list was down but in fact, it was my mail server blocking list messages because the Reverse DNS check failed for 'mail.pearsoncomputing.net'.
So, to my problem (Apologies again, if this gets duplicated);
I've been trying to clone the source repo for the last few days, using 'git clone' as per the wiki, but it keeps failing with various disconnection errors. The repo is painfully slow (worse than watching paint dry) which probably isn't helping. My connection here seems fine. I got 1.5G of data at one point before it failed but as far as I know, there is no way to restart from a 'git pull' failure. My latest attempt has been running for 9 hours and I've got 107M of data at less than 10KiB/s. Is the source available from anywhere else other than 'scm.trinitydesktop.org/scm/git/tde' or has anybody any ideas on how best to proceed?
Is this due to the size of the repo and http(s)? It used to work fine.
Cheers, Mike.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hi Guys,
Firstly, my apologies to Tim, Slavek, Michele and Francois as I sent them a direct email regarding this problem because I thought the mailing list was down but in fact, it was my mail server blocking list messages because the Reverse DNS check failed for 'mail.pearsoncomputing.net'.
Reverse DNS looks fine here (subdomain should not matter): 192.119.205.242 pearsoncomputing.net
So, to my problem (Apologies again, if this gets duplicated);
I've been trying to clone the source repo for the last few days, using 'git clone' as per the wiki, but it keeps failing with various disconnection errors. The repo is painfully slow (worse than watching paint dry) which probably isn't helping. My connection here seems fine. I got 1.5G of data at one point before it failed but as far as I know, there is no way to restart from a 'git pull' failure. My latest attempt has been running for 9 hours and I've got 107M of data at less than 10KiB/s. Is the source available from anywhere else other than 'scm.trinitydesktop.org/scm/git/tde' or has anybody any ideas on how best to proceed?
Is this due to the size of the repo and http(s)? It used to work fine.
The TDE servers are still in a bad physical location for Internet access, on top of residing in the United States where high speed Internet access is typically much harder to obtain than the rest of the world. Relocation is still being worked on with tentative scheduling for the middle of 2016.
Slavek has a (plain HTTP) mirror here: http://mirror.git.trinitydesktop.org/cgit/
Alternatively you can download the complete release tarball for R14.0.2; it contains the GIT SCM files such that you should only need to switch back to the master branch and pull (relatively small) updates from the master server: https://trinitydesktop.org/releases/R14.0.2/
Hope this helps!
Tim
On 02/12/2015 18:19, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hi Guys,
Firstly, my apologies to Tim, Slavek, Michele and Francois as I sent them a direct email regarding this problem because I thought the mailing list was down but in fact, it was my mail server blocking list messages because the Reverse DNS check failed for 'mail.pearsoncomputing.net'.
Reverse DNS looks fine here (subdomain should not matter): 192.119.205.242 pearsoncomputing.net
Hi Tim,
Thanks for getting back to me.
I've been getting hammered by spam so tried a few things, rDNS checks being one of them. Unfortunately, the mail server checks the rDNS for the host (mail.pearsoncomputing.net), the domain alone is not sufficient ( See results from 'mxtoolbox.com' - Your Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.)
I added an exception for pearsoncomputing.net but the rDNS check was rejecting other valid mail too so I've removed it.
The TDE servers are still in a bad physical location for Internet access, on top of residing in the United States where high speed Internet access is typically much harder to obtain than the rest of the world. Relocation is still being worked on with tentative scheduling for the middle of 2016.
Understood.
Slavek has a (plain HTTP) mirror here: http://mirror.git.trinitydesktop.org/cgit/
Thanks, I read this message in the archive before I started receiving list messages and I've started to clone Slávek's mirror. Though he did mention in his reply about a complication regarding the submodules.
Alternatively you can download the complete release tarball for R14.0.2; it contains the GIT SCM files such that you should only need to switch back to the master branch and pull (relatively small) updates from the master server: https://trinitydesktop.org/releases/R14.0.2/
I don't see any SCM files in the monolithic tar ball.
Hope this helps!
It does, very much, thanks.
Regards, Mike.
On Wed December 2 2015 23:53:51 Michael Howard wrote:
I've been getting hammered by spam so tried a few things, rDNS checks being one of them. Unfortunately, the mail server checks the rDNS for the host (mail.pearsoncomputing.net), the domain alone is not sufficient ( See results from 'mxtoolbox.com' - Your Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.)
I have been using rDNS checks for as long as I can remember and I don't see any problems with TDE lists. TDE list mails arrive here from 192.119.205.242. rDNS maps this to pearsoncomputing.net and DNS in turns maps that back to 192.119.205.242 so no problem.
I think you're running into problems checking HELO (or EHLO) rather than rDNS.
mail.pearsoncomputing.net is an A record with no PTR which is allowed but it might be better if it had a PTR (an IP can have more than one) or if mail.p... were a CNAME (which is allowed because it is not used in an MX record or NS record).
One doesn't usually check HELO that stringently but Tim might want to avoid the problem by setting "smtp_helo_name = pearsoncomputing.net" in main.cf.
--Mike
On 03/12/2015 08:39, Mike Bird wrote:
On Wed December 2 2015 23:53:51 Michael Howard wrote:
I've been getting hammered by spam so tried a few things, rDNS checks being one of them. Unfortunately, the mail server checks the rDNS for the host (mail.pearsoncomputing.net), the domain alone is not sufficient ( See results from 'mxtoolbox.com' - Your Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.)
I have been using rDNS checks for as long as I can remember and I don't see any problems with TDE lists. TDE list mails arrive here from 192.119.205.242. rDNS maps this to pearsoncomputing.net and DNS in turns maps that back to 192.119.205.242 so no problem.
I think you're running into problems checking HELO (or EHLO) rather than rDNS.
No, I'm running into problems running rDNS checks. As mentioned above, if you put 'mail.pearsoncomputing.net' into the search box at 'http://mxtoolbox.com/diagnostic.aspx' you will receive a warning from the 'SMTP Valid Hostname' test to the effect that 'Reverse DNS is not a valid Hostname'. The explanation of the warning, correctly states that;
'Your Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.'
Mail log extract;
2015-12-02 04:49:35 +0000 08 mail DNR:00000040: '192.119.205.242' found PTR 'pearsoncomputing.net' 2015-12-02 04:49:35 +0000 08 mail SMTP-IN:00000040: Reverse DNS check failed for <mail.pearsoncomputing.net> connected from <192.119.205.242> 2015-12-02 04:49:35 +0000 08 mail SMTP-IN:00000040: Set smtp explanation to [Reverse DNS check failed for <mail.pearsoncomputing.net> connected from <192.119.205.242>] 2015-12-02 04:49:35 +0000 08 mail DNR:00000040: Search MX for 'lists.pearsoncomputing.net' 2015-12-02 04:49:35 +0000 08 mail DNR:00000040: 'pearsoncomputing.net' found MX '192.119.205.242' with priority 0
Regards, Mike.
On Thu December 3 2015 01:04:30 Michael Howard wrote:
No, I'm running into problems running rDNS checks. As mentioned above, if you put 'mail.pearsoncomputing.net' into the search box at 'http://mxtoolbox.com/diagnostic.aspx' you will receive a warning from the 'SMTP Valid Hostname' test to the effect that 'Reverse DNS is not a valid Hostname'. The explanation of the warning, correctly states that;
rDNS-DNS checks are run on the connecting IP and show no problem with 192.119.205.242.
The only place I can find mail.pearsoncomputing.net is in the EHLO. SMTP HELO checks are notoriously sensitive and performing FCrDNS (DNS-rDNS-DNS) checks on them is very likely to encounter problems, is not recommended, and is considered by many postmasters to violate RFC 2821.
RFC2821 requires only that the SMTP HELO provide a resolvable name or an address literal. There is no requirement for rDNS or FCrDNS and if you do check the name you should allow the several forms of address literal in order to permit emergency communication between postmasters in the event of DNS issues.
Where is your Axigen server getting mail.pearsoncomputing.net if it's not from the EHLO? And why is it reporting an rDNS problem when it is actually performing a FCrDNS check?
//
Tim's setup is similar to yours. You have two A records (mail.dewberryfields.co.uk and dewberryfields.co.uk) mapping to 82.68.201.106 but only one PTR record in the reverse direction, in your case mapping to mail.dewberryfields.co.uk.
//
I recommend that you drop HELO/EHLO checks AND that Tim set his smtp_helo to pearsoncomputing.net.
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Wed December 2 2015 23:53:51 Michael Howard wrote:
I've been getting hammered by spam so tried a few things, rDNS checks being one of them. Unfortunately, the mail server checks the rDNS for the host (mail.pearsoncomputing.net), the domain alone is not sufficient ( See results from 'mxtoolbox.com' - Your Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.)
I have been using rDNS checks for as long as I can remember and I don't see any problems with TDE lists. TDE list mails arrive here from 192.119.205.242. rDNS maps this to pearsoncomputing.net and DNS in turns maps that back to 192.119.205.242 so no problem.
I think you're running into problems checking HELO (or EHLO) rather than rDNS.
mail.pearsoncomputing.net is an A record with no PTR which is allowed but it might be better if it had a PTR (an IP can have more than one) or if mail.p... were a CNAME (which is allowed because it is not used in an MX record or NS record).
One doesn't usually check HELO that stringently but Tim might want to avoid the problem by setting "smtp_helo_name = pearsoncomputing.net" in main.cf.
--Mike
As you can probably infer the main problem is that my ISP doesn't provide enough IP addresses (at a cost I am willing to pay) for all the services running here. From what I understand multiple rDNS records for the same IP is likely to cause more problems than it's worth as well.
After the servers are relocated next year there should be more IP addresses available, which will make this problem go away. I'm not all that keen on changing the HELO string as it isn't technically the domain that's identifying, it's that specific mail server, and over time there may be more than one mail server (for redundancy, etc.).
Since this has affected only one person in 5 years, I'm treating this like the DKIM problem for the moment; give it more time and it might go away. :-)
Tim
On 03/12/2015 19:16, Timothy Pearson wrote:
As you can probably infer the main problem is that my ISP doesn't provide enough IP addresses (at a cost I am willing to pay) for all the services running here. From what I understand multiple rDNS records for the same IP is likely to cause more problems than it's worth as well.
After the servers are relocated next year there should be more IP addresses available, which will make this problem go away. I'm not all that keen on changing the HELO string as it isn't technically the domain that's identifying, it's that specific mail server, and over time there may be more than one mail server (for redundancy, etc.).
Since this has affected only one person in 5 years, I'm treating this like the DKIM problem for the moment; give it more time and it might go away. :-)
Tim
It's certainly up to you how you run things, but it won't go away. :)
rDNS is really only important for mail servers but it is becoming increasingly important as the amount of spammers reaches astronomical proportions. An increasing number of servers will reject mail due to failed rDNS.
You could just get your ISP to point your IP's rDNS to your mail server hostname and your done. You won't need it for any of your other services and it will not affect any of your A records or CNAME records.
Regards, Mike.
On Thu December 3 2015 11:16:04 Timothy Pearson wrote:
As you can probably infer the main problem is that my ISP doesn't provide enough IP addresses (at a cost I am willing to pay) for all the services running here. From what I understand multiple rDNS records for the same IP is likely to cause more problems than it's worth as well.
I've heard of such problems but we ran with multiple PTRs from the mid nineties to the late noughties without problems. I imagine there was a time when people checked the first PTR record against the first A record but modern software knows to retrieve all records in a doubly nested loop and look for any match.
After the servers are relocated next year there should be more IP addresses available, which will make this problem go away.
With the world out of IPv4 address blocks the trend is to giving only one IPv4 address to each virtual or physical machine, and using RFC1918 addresses wherever possible.
Over the last two decades while growing our network we've reduced our public IPv4 addresses in several stages from 1025 (including the router's DS1 interface) to about a dozen public IPv4s which together support five locations across four cities.
The only machines with two public IPv4 addresses are some VPN+mail servers where the configuration is just too horrible without a second public IPv4.
You still occasionally see an ISP SWIPing a /29 to get their own utilization rate up but it's increasingly rare and if you want a second public IPv4 on a box you will now usually have to provide a written justification which will be assessed by a network engineer.
I'm not all that keen on changing the HELO string as it isn't technically the domain that's identifying, it's that specific mail server, and over time there may be more than one mail server (for redundancy, etc.).
The trend is toward giving a single name for each box with matching A and PTR records. You can still have multiple MX records pointing to multiple boxes. And you can still use CNAMEs or additional A records without PTRs to provide additional names for your box including for virtual web services.
Whether you call that box pearsoncomputing.net or mail.pearsoncomputing.net or something else doesn't really matter as long as A and PTR are consistent and preferably also /etc/hostname, /etc/mailname, and smtp_helo.
--Mike
-
Michael Howard -
Mike Bird -
Timothy Pearson