[Info-vax] Decuserve.org - Anyone know why it's down?

[John E. Malmberg]

On 1/5/2015 1:44 PM, Bill Gunshannon wrote:> In article 
<00AF0C71.35A9A1A4 at sendspamhere.org>,
<snip>
> This is the same problem run into by people using things like dyndns.

As long as they are relaying though an ISP or the Dyndns provided mail 
server, it should not matter if their MX receiver is on a dynamic IP 
address.

> Here's one (sanatized) taken directly from my servers maillog.
>
> Jan  5 00:05:22 mailhost postfix/smtpd[49341]: NOQUEUE:
> reject: RCPT from 67.107.123.196.ptr.us.xo.net[67.107.123.196]:
> 450 4.7.1 <mia-p-mail-01.int.ppcit.net>:
> Helo command rejected: Host not found; from=<xxxxxxx at pagepluscellular.com>
> to=<xxxxxx at cs.uofs.edu> proto=SMTP helo=<mia-p-mail-01.int.ppcit.net>
>
> Note that while the "helo" matches the name presented by the sending
> MTA (line 3) it does not match the PTR Record (line 2) and the email
> is rejected.

According to what has been explained to me, it is not valid to check the 
HELO/EHLO against the sending domain, and doing that as an absolute spam 
check is wrong.

Generally in legitimate e-mail, I do see that the EHLO/HELO does match, 
and in the case that it does match, I would be inclined to skip doing 
any additional content scanning.

About the only thing that I seen in spam with EHLO/HELO is a trick where 
the spammer sets the EHLO/HELO to the IP address of the MX that it is 
trying to spam.  It would seem to me that would be check that if an 
external mail server claimed to be my local mail server name or IP that 
it should be an easy call to reject.


The accurate anti-spam check for rDNS is much simpler:

LION> tcpip show host 96.252.127.67
Host address    Host name
96.252.127.67   static-96-252-127-67.bstnma.fios.verizon.net

LION> tcpip show host static-96-252-127-67.bstnma.fios.verizon.net
96.252.127.67   STATIC-96-252-127-67.BSTNMA.FIOS.VERIZON.NET

As long as the query for the rDNS by IP and the query for the name both 
match, everything is fine.  The actual name used by the mail server does 
not matter, and should not be involved in the check.

However ATT did a live test about 10 years ago, and determined that at 
least 10 % of legitmate e-mail servers could not pass that strict test.

So generally all a mail server can do is just validate that an rDNS has 
been assigned with out risking a false-positive.

The rDNS can also be checked to see if it indicates a dhcp or 
residential pool against a set of regexes.

AOL has not accepted e-mail from IP addresses with no rDNS at all for 
well over 10 years.  And as near as I can tell, if AOL is refusing 
e-mail based on a well known check, there is probably not any legitimate 
e-mail that would fail that check.

> It ain't rocket science but running a proper email server is harder
> than most people seem to think.  And if more of them were run properly
> SPAM would rapidly disappear.

Agreed.  The main reason that spam still exists is from people trying to 
do content filtering of spam instead of source IP filtering.

And it seems that the people most vocally worried about a legitimate 
e-mail getting mis-classfied as spam prefer to use the content filtering 
methods with the highest rates of silently discarding legitimate 
messages instead of far more accurate methods that reject detected spam.

They would rather silently loose dozens of legitimate e-mails a year 
instead of risking the extremely rare case of a legitimate e-mail ending 
up on an IP list because that mail server had a security breach.

But other than your statement about EHLO/HELO checks, I have not seen 
anyone else advocating EHLO/HELO checks on any of the anti-spam forums 
that I monitor.  The only memorable thread is were several mail server 
operators stated that EHLO/HELO should not be used directly for spam 
filtering when it was suggested.

Regards,
-John
wb8tyw at qsl.network
Personal Opinion Only