Re: Multi-Line Greetings A Certainty?
Sabahattin Gucukoglu <mail <at> sabahattin-gucukoglu.com>
2010-02-15 19:43:56 GMT
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.