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

[Bill Gunshannon]

In article <0ImdnXhknZjOEjHJnZ2dnUU7-cOdnZ2d at mchsi.com>,
	"John E. Malmberg" <wb8tyw at qsl.network> writes:
> On 1/6/2015 7:37 AM, Bill Gunshannon wrote:
>> 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?
> 
> Decuserve.org current rDNS is fine for e-mail for mainstream mail 
> servers, 

If by "mainstream" you mean mis-configured.  But then, as I have said,
that's probably most of them.  Thus the major SPAM problem.

>           and I bet we could set the EHLO/HELO to "april.fools" with out 
> any mail delivery issues showing up.

As I said, you can test it by sending email to me.  If you send
"HELO april.fools" here it will not fly.

> 
>>>
>>> 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.
> 
> While it will be impossible to convince you, the thread that explained 
> it to me was one that had many professional mail server operators on it 
> and they were all of the strong opinion that there was no value in doing 
> any checks on the HELO/EHLO message, that it was only logged for 
> diagnostic purposes.

If you are thinking only in terms of SPAM then yes, it is of limited
value but, as I said, it is tested for a totally different reason and
only catches SPAM as a side effect.  Your "professional mail server
operators" are just plain wrong.  If it was unneccesary and useless
why would checks even be built into MTA software?

> 
>> 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.
> 
> I have tracked the spam from "legitimate" sites.  These are sites from 
> all of the above that have security problems.  Based on analysis of the 
> spam, they have most of the following security issues:
> 
>     * Accepting a password authenticated user from IP with no rDNS.
> 
>     * Allowing weak passwords or users that fall for trivial phishing.
> 
>     * Having "test" accounts with easily guessed passwords active.
> 
>     * Allowing outgoing e-mail spoofed from well known web/trial
>       e-mail domains with out any association to the mail server domains.
>       Having that detection on outgoing e-mail is the fastest way to
>       detect if a user's account has been taken over.
> 
> For "political" reasons, I add those rDNS to my local blocking list on 
> Eisner.  It is unlikely that I would receive a legitimate mail from most 
> of them.

What!!  You don't think you wold ever receive a legitimate email from
someone using Verizon or AT&T.  You live in a rather strange world.

> 
>>>
>>> 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?
> 
> And you just confirmed why strict rDNS checks are not mainstream.

Incompetence of other operators is hardly reason for me to act incompetently
too.

> 
>>> 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.
> 
> In a perfect world, in the real world, any business that did that would 
> have their customers up in arms.

I do it.  And you know what, my customers aren't complaining.  They
actually like the way I run things (thus the reason they talked me
into coming back even after I retired when they couldn't find anyone
else who cold handle the job!!  :-)


> 
>>> 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.
> 
> I have kept statistics on the spam that has reached me on Eisner since 
> the PMAS was intalled.
> 
> No blocks on AOL, YAHOO, GMAIL, HOTMAIL.
> 
> Blocks on most other rDNS subdomains on first sight of spam, with only 
> the occasional expansion to IP pools.
> 
> 1344 Unique IP spam sources in approximately 10 years.
> 
>    16  Nigerian 419 Spams sent from AOL.COM servers.
>     3  Nigerian 419 spams sent from Hotmail.com servers.
>     6  Nigerian 419 spams sent from Outlook.com servers.
>     9  from spams from *.biz.rr.com
>        (The specific *.biz.rr.com was added to the block each time)
>    48  Mostly Nigerian 419 spams sent from Yahoo servers.
> 
> The stats are stilted because I have not blocked AOL/OUTLOOK/YAHOO and I 
> do block the other spam sources.
> 
> I think that PMAS was added to Eisner a bit over 10 years ago.
> 
> If I had blocked AOL.COM, it would have only blocked 16 additional 16 
> spams over 10 years.  Not significant in the spam flood.
> 
>>>> 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.
> 
> I block the insecure MTAs as a political statement, but until either AOL 
> refuses their e-mail, or spamhaus lists them, their security issues 
> probably will not get fixed.
> 
> If I do not recognize the rDNS of a spam source, I generally feel it is 
> safe to add that rDNS to my local blocking list.
> 
> I could not put such political blocks on a commercial e-mail server.
> 

Well, all of the blocks I have on our server are considered the proper
way to run an email server and can be found on dozens if not hundreds
of web sites explaining how to admin an email server.  I don't make
this stuff up.

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>