[Top] [All Lists]

Re: Multi-Line Greetings A Certainty?

2010-02-15 14:03:20

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

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.


<Prev in Thread] Current Thread [Next in Thread>