headers
Sabahattin Gucukoglu | 15 Feb 2010 05:31

Multi-Line Greetings A Certainty?


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
Permalink | Reply | 8 comments |
headers
John Levine | 15 Feb 2010 06:18

Re: Multi-Line Greetings A Certainty?


>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
Permalink | Reply | 1 comment |
headers
Hector Santos | 15 Feb 2010 06:30

Re: Multi-Line Greetings A Certainty?


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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hector Santos | 15 Feb 2010 06:52

Re: Multi-Line Greetings A Certainty?


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 15 Feb 2010 10:57
Picon
Favicon
Gravatar

Re: Multi-Line Greetings A Certainty?


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
Permalink | Reply | 1 comment |
headers
Hector Santos | 15 Feb 2010 11:56

Re: Multi-Line Greetings A Certainty?


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sabahattin Gucukoglu | 15 Feb 2010 19:54

Re: Multi-Line Greetings A Certainty?


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
Permalink | Reply | 0 comments |
headers
Sabahattin Gucukoglu | 15 Feb 2010 20:43

Re: Multi-Line Greetings A Certainty?


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,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hector Santos | 16 Feb 2010 00:17

Re: Multi-Line Greetings A Certainty?


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 blam
 e, and lose business and/or mindshare.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hector Santos | 17 Feb 2010 04:17

TLS and expired certs


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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane