Subject: Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
From: Sabahattin Gucukoglu <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 27 Feb 2010 06:57:11 +0000
List-Id: <ietf-smtp.imc.org>

On 26 Feb 2010, at 05:19, Dean Anderson wrote:
I get spam to hosts with MX records. I don't think removing MX records
> will have any effect on spam.  Spambots, aren't fully autonomous agents

I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to.  I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now).

It's not the first time, and this technique is still damned effective.  I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated.  Now I'm waiting for the TTL to expire the record on caches.  I'm convinced that is useful, anyway.  Sure, it's a short-term hack (like all spam countermeasures), but it works.  And why should we be afraid of standards compliance, in the very organisation that standardises?

> existing independently, they are programs written by people who want to
> conduct abuse for some purpose (annoyance, extortion, etc).
> 
The ones I'm talking about are distributed by viruses and trojan horses.  They run on Windows, of course.  They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process.  They barf when MX records fail to appear in a query result for MXs of a domain, for the most.

> Regarding the effect (if there even is one) of skipping domains without
> MX records, there are only two cases to analyze: Its either an oversight
> in the program, or its done on purpose.  Even supposing their current
> programs skip domains without MX records by some oversight, the spambot
> programmers will easily fix that.  Supposing the current programs skip
> domains without MX records on purpose, then do you really want to go
> along with whatever purpose that might be?  I wouldn't.
> 
Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have.  Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case.  On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called "ietf.org." and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there.  The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to death on redundantly-hosted mail servers.  And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently.

> But I do find it noteworthy that the IETF doesn't even follow its own
> recommendations on email.  The level of IETF spew, by which I mean
> telling other people what to do by issuing standards while not doing it
> themselves, grows more ever day.  This incident is another discredit to
> the IETF, particularly to the leadership of the IETF or perhaps the IETF
> secretariat, that I will have to document at IETF watch.

I want to say that I would *prefer* that MX records be published for host which *do not* receive mail.  This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached.  I also want to say that I am in support of the "Purist" point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently.  There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974.  I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far.  I would be much obliged if the required work were done for clarifying any opposing view to current standards.

Cheers,
Sabahattin

Date: Tue, 16 Feb 2010 22:17:51 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: TLS and expired certs
Sender: [email-masked]

In RFC 3207, section 4.1 it provides a guideline for a possible 
condition for MTA to reject a TLS session:

    The decision of whether or not to believe the authenticity of the
    other party in a TLS negotiation is a local matter.  However, some
    general rules for the decisions are:

    -  A SMTP client would probably only want to authenticate an SMTP
       server whose server certificate has a domain name that is the
       domain name that the client thought it was connecting to.

Why were possible expiration condition "insights" excluded from the 
production of this doc? if discussed at all?

I'm thinking of adding some time based rules for TLS rejection and 
just wondering if its worth it. Of course, this is to help automated 
MTA decision, not a MUA/MTA manual end-user question/decision.  I'm 
thinking something like:

    TLS Rejection Reasons:

      [X] Domain mismatch
      [X] Expired DAYS __60__

I guess maybe time has nothing to do with the fact that you reached
a matching TLS domain target?

Thanks for your insights

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Mon, 15 Feb 2010 18:17:08 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Sabahattin Gucukoglu <[email-masked]>
CC:  [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Sender: [email-masked]

Sabahattin Gucukoglu wrote:

> On 15 Feb 2010, at 05:30, Hector Santos wrote:
>> Sabahattin Gucukoglu wrote:
>>> I imagine it's more of an implementation robustness issue to support multiline greetings given the current text of RFC 5321.  However, Postfix's new postscreen daemon, docs http://www.postfix.org/postscreen.8.html , seems to be relying on it to do its job.  Also does something else disturbing (in typical Postfix experimental fashion) which is to disconnect clients just for not liking the initial "Teaser" banner.  According to the STANDARDS section, this is RFC 5321-stipulated stuff.  According to my experience, yeah, probably works for short enough timeouts, and I've seen plenty multiline greetings in the wild ...
>>> I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?
>> Only the good guys complain when are problems, not bad guys.
>>
> Yes.  That's because we have more scruples than spammers.  It's a good point in irony, though. :-)
> 
>> In my opinion, one of the strongest defense against spam is enforcing or mandating SMTP compliance.  Once you relax, it invites problem and uncertainty.
> 
> That is true, with the understanding that (a) spammers can and do catch up with the advancement of any threat to their techniques and (b) unfortunately, not all "Good guys" are indistinguishable from spammers themselves, leading to conservatism that is regrettably necessary.  This latter is particularly true when the author of the non-compliance has no justification to fix their broken implementations, usually because it has no business need (as compared to falling out with the conforming world).  Just to pick any old example, I can't write an MTA that doesn't accept spaces on either side of the brackets, in perfect conformance with RFC 5321 and with implementation benefits to myself, otherwise a very, very popular desktop application will not work with it, and *I* will be wrong, to blame, and lose business and/or mindshare.
> 

True that.  Like, I recall the OE  issue there. :)

So let me change my badly paraphrase of an old saying:

     "What is good for AOL and Microsoft, is good for Email!"

Basically, it appears in both cases, people had to accept because the 
really tall boys were doing something different than most and if you 
didn't accept it, you would lose business (and mindshare).

   OE issues a MAIL FROM:<space>      <- Your receiver supported it.
   AOL issues extended welcome lines  <- Your client supported it.

Personally, the space issue a was very minor "innocent" oops, compared 
to a very fundamental multi-line support issue. It would be really 
nuts if servers had to turn off multi-line responses, not just the
welcome but at each state, specially RCPT TO:, just because there 
*might* be one or more MTAs out there who didn't support it. I don't 
think any legit MTA can afford not to support it.

As mentioned in another post, we had ours OFF until AOL did it, and 
then turned it on by default.  I only recall two very early reports 
(2003/4 time frame?) from SMTP customers, if I recall, one had some 
user with an old FTP TO EMAIL gateway hub tool, TRANSACT?, the author 
fixed it, and the other was the old PHP mail command (internal or 3rd 
party script) which was quickly fixed or replaced once highlighted by 
the operator who was using it in some web mail form thing. I have not 
heard any "good guys" complain since then.  If so, and it was a 
constant issue, no doubt, it would be turned off in the default setup.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Subject: Re: Multi-Line Greetings A Certainty?
From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 15 Feb 2010 19:43:56 +0000
To: [email-masked]
Sender: [email-masked]

On 15 Feb 2010, at 05:30, Hector Santos wrote:
> Sabahattin Gucukoglu wrote:
>> I imagine it's more of an implementation robustness issue to support multiline greetings given the current text of RFC 5321.  However, Postfix's new postscreen daemon, docs http://www.postfix.org/postscreen.8.html , seems to be relying on it to do its job.  Also does something else disturbing (in typical Postfix experimental fashion) which is to disconnect clients just for not liking the initial "Teaser" banner.  According to the STANDARDS section, this is RFC 5321-stipulated stuff.  According to my experience, yeah, probably works for short enough timeouts, and I've seen plenty multiline greetings in the wild ...
>> I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?
> 
> Only the good guys complain when are problems, not bad guys.
> 
Yes.  That's because we have more scruples than spammers.  It's a good point in irony, though. :-)

> In my opinion, one of the strongest defense against spam is enforcing or mandating SMTP compliance.  Once you relax, it invites problem and uncertainty.

That is true, with the understanding that (a) spammers can and do catch up with the advancement of any threat to their techniques and (b) unfortunately, not all "Good guys" are indistinguishable from spammers themselves, leading to conservatism that is regrettably necessary.  This latter is particularly true when the author of the non-compliance has no justification to fix their broken implementations, usually because it has no business need (as compared to falling out with the conforming world).  Just to pick any old example, I can't write an MTA that doesn't accept spaces on either side of the brackets, in perfect conformance with RFC 5321 and with implementation benefits to myself, otherwise a very, very popular desktop application will not work with it, and *I* will be wrong, to blame, and lose business and/or mindshare.

Cheers,
Sabahattin

Subject: Re: Multi-Line Greetings A Certainty?
From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 15 Feb 2010 18:54:21 +0000
To: [email-masked]
Sender: [email-masked]

On 15 Feb 2010, at 05:18, John Levine wrote:
> I've used multiline greetings a lot, and I cannot remember any cases
> where a legit client MTA had trouble with them.  A really long one
> will indeed make some spambots barf.

Yes, I used them before realising they were affecting my spam load, however I have encountered a couple of instances, running really obscure software, that were affected.  I don't know whether, as pointed out AOL is now using them, this matters as much now that it did then (about 2001 I think).  I'm more worried by the use of rules which are only *just* specified, in passing.  They seem to be more the common trait of the spammer than a willful violation of standards, as such.

Cheers,
Sabahattin

Date: Mon, 15 Feb 2010 05:56:38 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: Sabahattin Gucukoglu <[email-masked]>, [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 
> On 02/15/2010 05:31 AM, Sabahattin Gucukoglu wrote:
>> I don't like spam either, but does this not strike others as being 
>> really quite dangerous thinking and uncertain games to be playing?
> 
> It was uncertain back in 2004. Not now.
> 
> I can't even remember what problems it caused. Around 2005 they had 
> already been solved.

Which probably coincided when AOL started (probable closer to 2004 if 
I recall) to spit out extended welcome lines, thus forcing the issue 
with any remaining legit but broken MTAs if they wanted to be able to 
co-exist with AOL servers.

But there are still out there and today its all bad guys using low/no 
cost poor MTA code or using "i don't care" blasting code.  Today,  it 
around 5-8% of the hits on server.  Back in 2003, it as around 15% but 
as high as 30% during the holidays!

2003 to current daily stats stored at (HELO column).

         http://www.winserver.com/SpamStats

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Mon, 15 Feb 2010 10:57:12 +0100
From: Arnt Gulbrandsen <[email-masked]>
Organization: http://arnt.gulbrandsen.priv.no
To: Sabahattin Gucukoglu <[email-masked]>
Cc: [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Sender: [email-masked]

On 02/15/2010 05:31 AM, Sabahattin Gucukoglu wrote:
> I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?

It was uncertain back in 2004. Not now.

I can't even remember what problems it caused. Around 2005 they had 
already been solved.

Arnt

Date: Mon, 15 Feb 2010 00:52:51 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Sabahattin Gucukoglu <[email-masked]>
CC:  [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Sender: [email-masked]

Sabahattin Gucukoglu wrote:

> Hi all,
> 
> I imagine it's more of an implementation robustness issue to support multiline greetings given the current text of RFC 5321.  However, Postfix's new postscreen daemon, docs http://www.postfix.org/postscreen.8.html , seems to be relying on it to do its job.  Also does something else disturbing (in typical Postfix experimental fashion) which is to disconnect clients just for not liking the initial "Teaser" banner.  According to the STANDARDS section, this is RFC 5321-stipulated stuff.  According to my experience, yeah, probably works for short enough timeouts, and I've seen plenty multiline greetings in the wild ...
> 
> I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?
> 
> Cheers,
> Sabahattin
> 

As a follow to my last response. Our settings was OFF by default with 
a template display.  When AOL began to do it, our next update had it 
on by default.

Keep in mind it is against the law (in the US) to abuse a computer. 
AOL really didn't do it because they knew their are broken clients out 
there. It was required by US federal law and I recall it was added 
after that big AOL lawsuit they won against a spammer a few years 
back.  It as the equivalent as required by the US EPCA for online host 
systems to provide/show the TOS on their system.

So to badly paraphrase an old GM saying:

        "Whats good for AOL, is good for Email!"

<g>

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Mon, 15 Feb 2010 00:30:15 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Sabahattin Gucukoglu <[email-masked]>
CC:  [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Sender: [email-masked]

Sabahattin Gucukoglu wrote:

> Hi all,
> 
> I imagine it's more of an implementation robustness issue to support multiline greetings given the current text of RFC 5321.  However, Postfix's new postscreen daemon, docs http://www.postfix.org/postscreen.8.html , seems to be relying on it to do its job.  Also does something else disturbing (in typical Postfix experimental fashion) which is to disconnect clients just for not liking the initial "Teaser" banner.  According to the STANDARDS section, this is RFC 5321-stipulated stuff.  According to my experience, yeah, probably works for short enough timeouts, and I've seen plenty multiline greetings in the wild ...
> 
> I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?
> 
> Cheers,
> Sabahattin

Only the good guys complain when are problems, not bad guys.

Per 8 years of on-going daily statistics, ~5-8% drop because they 
don't understand multi-line responses.  There are all bad guys with a 
two exceptions in the past, both good guys who quickly fixed their bug 
once they were made aware.  No one needed to be shamed and a serious 
implementation is stubborn to fix it, they should be shamed. Its not 
your problem, its theirs.

A server could of course have an connection IP whitelist to avoid 
sending extended welcome responses. But the problem isn't with known 
associations, its the anonymous world that is a plaque.

In my opinion, one of the strongest defense against spam is enforcing 
or mandating SMTP compliance.  Once you relax, it invites problem and 
uncertainty.

-- 
Sincerely

Hector Santos
http://www.santronics.com

From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: Multi-Line Greetings A Certainty?
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>I don't like spam either, but does this not strike others as being
>really quite dangerous thinking and uncertain games to be playing?

I've used multiline greetings a lot, and I cannot remember any cases
where a legit client MTA had trouble with them.  A really long one
will indeed make some spambots barf.

R's,
John

From: Sabahattin Gucukoglu <[email-masked]>
Subject: Multi-Line Greetings A Certainty?
Date: Mon, 15 Feb 2010 04:31:21 +0000
To: [email-masked]
Sender: [email-masked]

Hi all,

I imagine it's more of an implementation robustness issue to support multiline greetings given the current text of RFC 5321.  However, Postfix's new postscreen daemon, docs http://www.postfix.org/postscreen.8.html , seems to be relying on it to do its job.  Also does something else disturbing (in typical Postfix experimental fashion) which is to disconnect clients just for not liking the initial "Teaser" banner.  According to the STANDARDS section, this is RFC 5321-stipulated stuff.  According to my experience, yeah, probably works for short enough timeouts, and I've seen plenty multiline greetings in the wild ...

I don't like spam either, but does this not strike others as being really quite dangerous thinking and uncertain games to be playing?

Cheers,
Sabahattin