Hi all, I was wondering if this has been considered or done before: an SMTP server configured to receive email data, perform the required checks on it, and NOT send an OK reply to the DATA command if the email is to be rejected.
I quote this paragraph from RFC 2821 (correct me if I'm quoting the wrong RFC on SMTP, I'm not exactly an expert on this): >From chapter 4.1.1.4 on SMTP's DATA command: "... If the processing is successful, the receiver MUST send an OK reply. If the processing fails the receiver MUST send a failure reply. The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive completion reply to the end of data indication, the receiver takes full responsibility for the message (see section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in section 4.4." So this behaviour would be somewhat against RFC guidelines, but I'd like you to consider what I think are major benefits to this kind of "preemptive rejection". When you accept an email and later reject it, you have to inform the sender by sending another email (like you're supposed to, according to the RFCs): 1. You use up server resources sending back one email for every unsolicited email you get (which can be a b**** depending on your daily dose of spam) 2. you bother the hell out of spoofed email addresses (unless some kind of check is performed for every sender) 3. You're generating extra traffic on the net Wouldn't it be a lot simpler if we could just reject an email at the SMTP level, before it ever gets, well... accepted? We would then be transfering responsability to the SMTP client or relay on reporting the delivery failure to the sender (along with a human-readable explanation that would actually inform the reason for rejection to the sender), which I believe most of them do already. I'd love to hear thoughts on this! -- Dan Ferreira _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
