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