[Greylist-users] Up and running on the real sever - and I

[William Blunn]

James J Dempsey wrote:
> William Blunn <bill--greylist at tao-group.com> wrote:
>> he RFCs are useful as a starting point, and for quoting at people *under
>> certain circumstances* ... but slavishly following them is not always
>> the best path.
>
> I know what you are trying to say, but I think it is a dangerous slippery
> slope. The RFCs are the law that explains the protocol between two remote
> hosts. If hosts start doing whatever they want, then we are never going to
> get mail delivered.

Anything "you" (a sensible citizen) generate should be within the specs. 
Bending the rules should be kept to how "you" interpret data from other 
entities.

> Certainly in a case where there is a problem between two hosts, the 
> one that didn't comply with the RFC is at fault. Period.

Yes, the one that doesn't comply is at fault. But, as an administrator, 
what should I do if a prospective customer is trying to send me an 
e-mail, and the only fault is that their HELO reads "HELO NTSERVER"?

The remote sysadmin is overworked and undercompetent. They don't know 
how to change the HELO parameter, and they wouldn't have the time even 
if they did. "Everyone else" can receive e-mail from them, so why can't you?

This is not a contrived example. This actually happens. In the first and 
second instances I relaxed the restriction for their hosts. Later I 
switched that particular HELO checking rule off completely.

> As an example of why we have RFCs: I've always hated the blatant 
> misspelling
> of the SMTP HELO command. I'm going to change my mail transport to use 
> HELLO
> instead. Clearly this is an improvement.

This example is specious. Without being paid a proper fee, I'm not here 
to hand-hold people and explain why certain things are snake-oil and 
other things aren't. I'll provide some pointers which people might find 
useful, but they'll have to decide for themselves. If people want to be 
told what to do, it'll have to be on a consultative basis.

Bill
-- 
The contents of this e-mail and any attachments are confidential and may 
be legally privileged.  If you have received this e-mail and you are not 
a named addressee, please inform us as soon as possible on 
+44 118 901 2999 and then delete the e-mail from your system.  If you 
are not a named addressee you must not copy, use, disclose, distribute, 
print or rely on this e-mail.  Any views expressed in this e-mail or any 
attachments may not necessarily reflect those of Tao's management.  
Although we routinely screen for viruses, addressees should scan this 
e-mail and any attachments for viruses.  Tao makes no representation or 
warranty as to the absence of viruses in this e-mail or any attachments.  
Please note that for the protection of our business, we may monitor and 
read e-mails sent to and from our server(s).