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

[Bill Gunshannon]

In article <WdCdnYkrc57GrjbJnZ2dnUU7-K-dnZ2d at mchsi.com>,
	"John E. Malmberg" <wb8tyw at qsl.network> writes:
> 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.

True.  But would someone like decuserve.org use some other relay MTA?

> 
>> 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.

Well, it was explained wrong.  If the HELO/EHLO does not match the real
DNS returned name the system is considered spoofing.  While this affects
SPAM, that is not what is being tested and there are other reasons to
spoof (and to protect from spoofing) than SPAM.

> 
> 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.

Why?  I receive SPAM from legitimate sites all the time.  AT&T, Verizon,
Comcast, almost anything from Brazil.  Not all SPAM comes from zombied
PC's.

> 
> 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.

IP Addresses are not valid in HELO/EHLO so that should be rejected
immediately.

> 
> 
> 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.

You really need to learn how email is supposed to work.  You are doing
the test backwards.  If you start with the PTR pretty much anything
will match, even zombied PC's.  

> 
> 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.

I would agree with that.  Just like my Picatinny Arsenal example.
That's a major DOD site with email servers maintained by high-priced
contractors at 7th Signal at Ft. Huachucca, AZ.  Not only were the
machines mis-configured but the contractors couldn't comprehend how
and couldn't understand even when given the solution.  Any reason to
expect some mom&pop ISP to have better qualified techs?


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

No, it can reject email from misconfigured MTA's, as it should.

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

That's done, too, but is a totally different solution to a totally
different problem.

> 
> 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.

Which is just plain funny.  AOL always was one of the biggest SPAMers
the INTERNET ever saw.  While I can't just blanket block them at the
server I have not, personally, accepted any email from AOL in decades.

> 
>> 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.

How does one do "source IP filtering" to stop SPAM when much of it comes
from legitimate MTA's?  The best one can do is block machines that have
no business sending email (as an MTA) in the first place.  And one of the
best ways of doing that is refusing machines with mis-matched A and PTR
Records.

> 
> 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.  

Probably because it si not an anti-SPAM measure.  This is something that
should be dealt with long before the issue of SPAM is considered.  As I
said, it is a spoofing issue. not a SPAM issue.  The fact that many SPAM
sites spoof does not change the order of consideration.  There are a lot
of other reasons for spoofing that have nothing to do with SPAM that are
much more serious threats.

>                 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.

And, they were right.  Spoofing is spoofing.  SPAM filtering comes later
in the process.

bill


-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>