[TriLUG] recent "Poor Reputation Sender" bounces

[Joseph Mack NA3T via TriLUG]

On Tue, 9 Jul 2019, Matt Flyer via TriLUG wrote:

> I gather that Joe's intended recipient uses mimecast as their mail
> receiver from the "au-smtp-inbound-2.mimecast.com" 

presumably.

I got another poor reputation message last week for a US e-mail address. I 
assume someone is tightening the screws a little harder.

Here's that message (e-mail address deleted)

"
Final-Recipient: rfc822; <recipient's e-mail address>
Action: failed
Status: 4.0.0
Remote-MTA: dns; mailstore1.secureserver.net
Diagnostic-Code: smtp; 554 p3plibsmtp02-12.prod.phx3.secureserver.net CMGW
     IB103. Connection refused. 208.79.82.66 has a poor reputation on Cloudmark
     Sender Intelligence (CSI). Please visit
     http://csi.cloudmark.com/reset-request/?ip=208.79.82.66 to request a
     delisting.
"

> According to Mimecast, the error code 550 is issued when "Anti-Spoofing 
> policy - Inbound not allowed" and is triggered by their anti-spoofing
> policy.  The error code 503 is used for non-existent user.
>
> Consequently, it sounds like they flagged the sender as potentially
> spoofed, which could explain Joe's intermittent results.  Looking over
> one of the trilug messages, I see that my MX received the message from
> pilot (Received: from pilot.trilug.org (2098.x.rootbsd.net
> [208.79.82.66]) and that it has a valid SPF record. I do see that it
> triggered an automatic reverse lookup which does show it being
> rootbsd.net, not trillug.org - which is probably the reason it got
> flagged.
>
> As a side note, a quick RBL check on MxToolbox for pilot.trilug.org
> shows now issues with a large number of RBL services checked, so the
> spam reputation of Pilot should not be an issue. 
>
> Additionally, I noticed when attempting to SSH in from an IPV6 capable
> host, that it wants to use the address: 2001:470:8:11ec::2 which also
> shows clear on the RBL front. 

well I'm not dexterous enough with e-mail to have known to do any of these 
things. Thanks for checking them out.

> You are correct that the NAT issue is immaterial in this regard as it
> is the public IP that matters. 

OK

> In response to Joe's comment, I don't think vm-net

so that's our host. I didn't know who they were.

> is doing a many to one NAT and using the public IP (208.79.82.66) for multiple 
> hosts.  I think it is dedicated to Pilot which nmap shows the typical ports 
> for an ssh, web, and email server.

yes, just checked.

> A many to one works well for a large number of outbound connections

doh. Of course.

> where the router can assign a random port number for each connection and 
> receives the corresponding return traffic to that port.  It doesn't work so 
> well for servers that receive inbound connections at default ports, e.g. HTTP, 
> and SSH.  If they were sharing the IP address with multiple hosts, how would 
> it know which one to send the inbound traffic to? Even if they're using SNI, 
> it would not be reliable or work for all services.

yes. doh again.

So the bad reputation isn't from others NAT'ing behind 208.79.82.66, it's from 
our users?

> Therefore, they should be able to set the reverse lookup in the host
> configuration and if they can it is probably wise as more and more
> email recipients, such as gmail, will bounce when the reverse DNS
> doesn't match, even if you have a valid spf record and DKIM signature.

Is it possible to fix the reverse DNS to future proof us?

Andre says the reverse DNS is not the problem

> Even setting a reverse or a different reverse should not change the current bounce.

You seem to have checked a bunch of things, that are OK. I don't know yet what 
the problem is

o bad reputation?

o reverse DNS doesn't match?

o something else?

Thanks Joe

-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant
map generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!