"Scott D. Yelich" <[EMAIL PROTECTED]> wrote:
>(1) Is it better to write an SMTPd that is strict to the RFCs or
>lenient?
The "robustness principle" says: be conservative in what you send, but
liberal in what you accept. In other words, adhere to the RFC's
strictly in anything your daemon sends, but don't strictly enforce the
RFC's on commands it receives from others just for the sake of
compliance.
E.g., if a client sends you "mail from:[EMAIL PROTECTED]", you can
accept it, but when sending "mail" commands, you should use the valid
syntax "mail from:<[EMAIL PROTECTED]>".
>That is, where does one go to settle disputes -- or is it
>better to sit back and miss mail due to differences in interpreting
>the RFCs?
There's Internet Police Department to which you can report RFC
offendors. End users will probably not be impressed that you're
bouncing their mail due to petty protocol errors. However, not all
protocol errors are minor.
>(2) Are there any tools to thoroughly test a prospective SMTPd
>against RFC compliance?
Don't know of any.
>Is anyone interested in such a tool?
Probably some SMTP implementors.
>(3) qmail accepts "mail from:" and "rcpt to:" without parameters. The
>"data" command is then allowed, a message body can be entered, and is
>accepted with a 250 after the dot line. Is this correct?
Sure, why not? qmail will attempt to deliver the message to all listed
recipients and report and errors to specified sender. :-)
-Dave
