[TriLUG] recent "Poor Reputation Sender" bounces

[ac via TriLUG]

On Wed, 10 Jul 2019 17:02:20 -0400
Matt Flyer via TriLUG <trilug at trilug.org> wrote:
> On Wed, 2019-07-10 at 16:30 +0000, Joseph Mack NA3T via TriLUG wrote:
> > On Wed, 10 Jul 2019, ac via TriLUG wrote:
> >   
> > > 
> > > http://multirbl.valli.org/lookup/208.79.82.66.html  
> > thanks Andre,
> >
Pleasure Matt :)
 
> > I'm unfamiliar with many of your tests.
> > 
The problem with tests are that there are 'groups' (whom operate more
like 'gangs' than groups) and these all have their own preferred
methods of checking incoming email. Of course this results in there
being 100's of 'experts' that are all sure that their own testing
protocols
is the alpha and omega.

The link to valli.org above is the only 'balanced' combination which
includes all the 'groups'  including spamhaus, senderscore as well as
the internationals, the EU, Chinese and RU etc etc 

In the case of Pilot, only one group had an issue: senderscore - but
that one group is enough to cause a false positive bounce as Mimecast
(a corporate spam @noreply relay service) trusts high....

Pilot would have no issues delivering to Google, Microsoft c-panel
and everyone else....

When testing mail delivery it is important to test as balanced and
as widely as possible - as your users may want to send email to
China, Russia or EU and Africa, etc. 

> > However I went to the URL above and saw the results. We have about a
> > dozen fails 
> > because our(?) DNS server was not accessible. I have no idea how
> > serious this 
> > is.  
> I've never seen these reputation tests before either, quite
> interesting.  
> 
> Actually this post came up at a convenient time.  It turns out I
> started having this problem with my (email) server recently.  
> 
> Here's the background information: It is a Linode server that runs
> multiple (web) domains and (virtual) email domains.  As SNI is
> unreliable, the machine has two IPV4 addresses, and a bank of IPV6
> addresses (one is assigned - I have some questions / issues on this
> for a different thread).
> 
ipv6 is on 'whitelist' only - so, if you are relaying email from ipv6
resource you need to get into the whitelist, I am also starting to use
ipv6 for email relay myself, so will document the process and learn all
the lessons IRL :)

> The one domain and IP address is used as a local forum.  The other I
> use for my private stuff.  Postfix had defaulted to using the forum IP
> address as the outbound SMTP.  This wasn't a problem as I had SPF and
> DKIM records set up for both.  Reverse DNS worked for both.  
> 
Okay, SPF is supported broadly but DKIM not so much. For my email
servers I have not bothered with DKIM at all as the load and overhead
makes differences in my outgoing que, it eats into profits and provides
nothing, so I do not do or worry about DKIM at all. DKIM is also fully
used by the spammers as well as criminal syndicates, so you are more
likely to find fully implemented DKIM in SPAM, than not :)

Reverse DNS is an issue, as when IP ranges are hijacked the ranges more
often than not, does not have reverse dns. So... many email admins
simply DROP anything with no reverse zone - which is not want RFC says
btw... - So, here we find another practice in real life, done by a
majority of independents, which is non rfc...

So, yes, having reverse DNS when operating an email server is essential.

here is a quick essentials list:

Five essential things: (1) Reverse DNS  (2) SPF (3) IP reputation (4)
ipv4 (5) Properly configured postfix/exim/etc.

Non Essential / Do not need to have : (1) DKIM (2) can have '~' on SPF 
(softfails are scored low by all groups)

Under IP reputation: Not a dynamic ip (must be in static range, must be
'clean' for at least the major groups/gangs and not listed by more than
15 of the minors. I have found that if you exceed 15 of the minors then
you also bounce and from groups like google and microsoft, which means
that they also 'use' the minors in some way...

> The only potential 'gotcha' that I caught (yesterday) was the the IPV6
> address was in the AAAA record for the forum IP and the reverse was
> set to my private domain.  This was an left over from some previous
> configuration.
> 
> Anyway, on July 5th Spectrum / RoadRunner (a lot of people still use
> RR addresses) started blocking the server. Example error: Jul  9
> 09:08:54 telvos postfix/smtp[14815]: CDED51F99B:
> to=<redacted at triad.rr.com>,
> relay=dnvrco-cmedge01.email.rr.com[69.134.155.135]:25, delay=172706,
> delays=172706/0.02/0.28/0, dsn=4.0.0, status=deferred (host dnvrco-
> cmedge01.email.rr.com[69.134.155.135] refused to talk to me: 554
> dnvrco-cmimta05 esmtp ESMTP server not available AUP#I-1000)
> 
> From what I can tell, the 554 means invalid r-dns and the AUP#I-1000
> means blocked.  This really puzzles me as the reverse DNS on the IPV4

Okay, as seen with Pilot, as an example, the groups (gangs) all rape
the bounce codes, so a bounce code does not help much in general and
only relates to that group and even then it means not much...

Google re-writes bounce to reflect a sender error, which is quite EVIL.

(Example: If you would bounce an incoming email from Google server,
Google will send bounce notification to the product (the google user),
that the sender has a hardware read error... whereas the sender sent:
'550 - High probability of spam as IP is sending spam right now' -
google would tell the product the recipient email server has a hardware
issue

So, anyway, 554 in your above example could mean anything :)
Check the actual group 554 bounce for their definition of what a 554
'server not available' means... (even then, in your example, it is also
rubbish...so...means nothing)

> (the interface being used) was fine and resolved to the same as the
> forward domain.  Mxtoolbox indicated no issues with the domain and it
> is not blacklisted.  In fact, I have been getting the weekly reports
> for this address for almost two years without showing any issues.
> Today I ran the reputation tool and it gave this domain a score of 99
> out of 100.  I do not send bulk or unsolicited email, except perhaps
> to the legislators.
> 
> I have zero clue as to why this was being blocked.
> 
Go through my list of essentials above

> What I did was figure out how to smtp_bind Postfix to the other IP
> address, which basically switched it to the other domain, my personal
> one.  This too has an SPF record and DKIM.  Work around worked.
> 
> However, as best as I can tell, there is no real way to try to contact
> Spectrum (Rectum as I call them) to inquire what the hell is causing
> them to block the other IP?
> 
yes, there is, but first run though the essentials for your own IP
number or post your mail server ip, also, both the triad.rr.com mx has
pri of 10 and one was down when I accessed them with telnet, so it may
well be that this is just a standard outage :)
the two are 69.134.155.135 and 69.134.155.136...

hth

Andre