Re: problems sending to prodigy.net hosted email

[Stephen Satchell]

On 03/09/2018 01:23 PM, Trey Nolen wrote:

We are having issues with domains hosted on prodigy.net email servers
including att.net, bellsouth.net, and scbglobal.net.

We are being rejected for bad reverse DNS, but DNS is setup correctly.
The error we are receiving is:
Remote host said: 550 5.7.1 Connections not accepted from servers
without a valid sender domain.flph829 Fix reverse DNS for 74.252.14.252

I leave it up to the reader to test the validity of 74.252.14.252, but
every test we've done looks good.


The MX records for these domains indicate this (identical on the three
domains mentioned above):
;; ANSWER SECTION:
att.net.        175    IN    MX    5 al-ip4-mx-vip1.prodigy.net.
att.net.        175    IN    MX    5 ff-ip4-mx-vip2.prodigy.net.
att.net.        175    IN    MX    5 ff-ip4-mx-vip1.prodigy.net.
att.net.        175    IN    MX    5 al-ip4-mx-vip2.prodigy.net.


(Cavaet:  it's been a long, LONG time since I have sent ANY mail to 
prodigy.net, att.net, bellsouth.net, or sbcglobal.net.  So I don't have 
any advice specific to sending mail to servers hosting domains on those 
services.  Rather, I've concentrated on what I understand to be Best 
Practice for mail admins.)



[satch@c74-admin ~]$ dig +short -x 74.252.14.252
mail.internetpro.net.
[satch@c74-admin ~]$ dig +short mail.internetpro.net.
74.252.14.252


OK, forward and reverse match.

One interesting point:  When I did the full reverse lookup of the IP 
address (without the +short), this was part of the ADDITIONAL SECTION:



ns2.internetpro.net.5999IN  A   74.252.14.252


I would suspect that some people would look at you oddly when your mail 
server is also one of your authoritative name servers.  I know it's 
stupid, but mail admins have for years been trying to figure out 
behavioral habits and stigmata of spammers.  Are you short of IP 
addresses, or stingy with servers?


(I know in my consulting practice I strongly discourage having ANY other 
significant services on DNS servers.  RADIUS and DHCP, ok, but not mail 
or web.  For CPanel and PLESK web boxes, have the NS records point to a 
pair of DNS-dedicated servers, and sync the zone files with the ones on 
the Web boxes.)


That said, I think I see a potential set of problems.  The TTL on your 
PTR record is too short.  Best Practices call for the TTL to be at least 
86400, if not longer.  Snowshoe spammers tend to have short TTLs on DNS 
records so that it's easy to shift to cleaner IP addresses when the 
current IP address' reputation is sullied by ne'er-do-well customers or 
hijackers.


6000 is only 1.5+ hours.  In all the formulas I've seen published, the 
accepted TTL was NEVER less than 14400, or four hours.


And your name server record TTLs should be MUCH longer, like 864000 (10 
days).  Too short a TTL for NS (and SOA) records can be a big red flag 
for some mail operators.


What does SPF say for the domains in question?  Also, what is the TTL on 
the TXT records?

Re: BCP 38 addendum

[Baldur Norddahl]

I have a router that takes a long time to converge after reboot. To fix
that I do not want to advertise my prefixes until the router is fully
ready. But I still want to establish the BGP sessions otherwise the router
will never be ready. So we program in a delay until advertising after BGP
session established.

Now if my peers automatically converted BGP announced prefixes into ACLs,
they would blackhole any traffic that might come to this router during
startup. This is obviously not good.

BGP announced prefixes tells you what I can receive but not what I can
send. Interpreting that any other way is abusing the protocol. You would
need a new BGP extension so we could announce what we might send
independent of what we want to receive.

IRR generated ACL filters might work if agreeable by the peer.

Regards

Baldur

Re: Amazon peering peeps on the list?

[Joe Hamelin]

 On Mar 9, 2018 8:27 AM, "Joe Nelson"  wrote:

> I've all but given up on trying to get a response from peer...@amazon.com.


Heh, that was me 17 years ago.

--
Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474


>

problems sending to prodigy.net hosted email

[Trey Nolen]

We are having issues with domains hosted on prodigy.net email servers
including att.net, bellsouth.net, and scbglobal.net.

We are being rejected for bad reverse DNS, but DNS is setup correctly. 
The error we are receiving is:
Remote host said: 550 5.7.1 Connections not accepted from servers
without a valid sender domain.flph829 Fix reverse DNS for 74.252.14.252

I leave it up to the reader to test the validity of 74.252.14.252, but
every test we've done looks good.


The MX records for these domains indicate this (identical on the three
domains mentioned above):
;; ANSWER SECTION:
att.net.        175    IN    MX    5 al-ip4-mx-vip1.prodigy.net.
att.net.        175    IN    MX    5 ff-ip4-mx-vip2.prodigy.net.
att.net.        175    IN    MX    5 ff-ip4-mx-vip1.prodigy.net.
att.net.        175    IN    MX    5 al-ip4-mx-vip2.prodigy.net.



Everything we can find on the postmaster pages, forums, etc. point to
emailing abuse_...@abuse-att.net.  We have done this and received their
autoresponder.  We've waited the requisite 48 hours and emailed again
for an escalation only to receive another autoresponder with another
ticket number attached (even though we emailed with a ticket number in
the message).    This has now been ongoing since at least March 4, when
we received our first complaint and we have yet to hear anything from
AT   We don't currently have any direct contacts for Prodigy.net.


I will say that the 75.252.14.0/24 netblock is owned by AT and I'm
wondering if that might be causing the issue.  For instance, they are
trying to do a local lookup of the PTR record instead of contacting the
delegated servers.


I'm hoping someone here has a point of contact which I might reach out
to in order to correct this issue.  Any help would be appreciated.


Trey Nolen