2 Dec
2015
2 Dec
'15
9:12 a.m.
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.
--
Mike Howard
2 Dec
2 Dec
10:19 a.m.
New subject: [trinity-devel] GIT Problems - Cloning TDE Source
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iFYEARELAAYFAlZfNjIACgkQLaxZSoRZrGGFsADfboNvQjIMrjtL8/NltXFq7Kol
mJ8xNouC9USE/QDgusnCgraCBHfPkCJ1pOiK5SguMFzvnkKH2GxpLw==
=8xnN
-----END PGP SIGNATURE-----
11:53 p.m.
New subject: [trinity-devel] GIT Problems - Cloning TDE Source
On 02/12/2015 18:19, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
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.
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 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.
--
Mike Howard
3 Dec
3 Dec
12:39 a.m.
New subject: TDE list rDNS/HELO
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
1:04 a.m.
New subject: [trinity-devel] TDE list rDNS/HELO
On 03/12/2015 08:39, Mike Bird wrote:
On Wed December 2 2015 23:53:51 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;
'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.
--
Mike Howard
Lancashire
England
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.
11:16 a.m.
New subject: [trinity-devel] TDE list rDNS/HELO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Wed December 2 2015 23:53:51 Michael Howard 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
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 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iFYEARELAAYFAlZglPQACgkQLaxZSoRZrGHeuQDeKchHK/k/UohhsEhfdk09I9eW
qSDFAfjXF/JBJgDeLmVKCabJuL7XCa/7FZKHxIsiFwPuDdccHvILXA==
=m1aX
-----END PGP SIGNATURE-----
11:37 a.m.
New subject: [trinity-devel] TDE list rDNS/HELO
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.
--
Mike Howard
12:43 p.m.
New subject: [trinity-devel] TDE list rDNS/HELO
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
1:47 p.m.
New subject: [trinity-devel] TDE list rDNS/HELO
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
3090
days inactive
3091
days old
8 comments
3 participants
participants (3)
-
Michael Howard -
Mike Bird -
Timothy Pearson