I asked John, who is the author of the RFC his opinion. Here is his response.
> -----Original Message----- > From: John C Klensin [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, December 05, 2001 8:43 PM > To: Schwartz, Jim > Subject: Re: RFC2821 > > The answer, unfortunately, is "yes". There is actually a third > way to do this, which is to accept the traffic and then return > an error message to the return-path (the MAIL FROM field of the > incoming message), with a MAIL FROM on the outgoing message set > to null (i.e., MAIL FROM:<>) > > Now, if you want a personal opinion based on a certain amount of > experience, I'd say that one should avoid your second option > (accepting DATA and then generating a 554 (or something else). > If you are trying to do relay-blocking, you have as much > information at RCPT time as you do after you've spent your > resources absorbing the nonsense and there is no point in > wasting those resources. By contrast, if you reject all > addresses at RCPT time, the sender is forbidden to even send a > DATA command (that prohibition is violated sometimes, but that > is that point at which a sensible server implementor might go > outside the standard a bit and close the connection). > > More generally, the argument for making the decision at RCPT > time and rejecting then is that you want to use up as few of > your resources as possible and, in principle, that does it. > > Conversely, that is the argument for sending the error > information back as a mail message: experience with real > spammers indicates that they often take _any_ non-success > response code to RCPT as "try again later" so that, rather than > minimizing the use of resources, you inflict a DoS attack on > yourself. On the other hand, a good deal of spam contains > return-path arguments that are bogus (note 1) and you don't want > to be retrying for days. I don't know that anyone has actually > done it, but it would seem to me that a good resource-conserving > algorithm would be to: > > (1) Notice, at RCPT time, that the address was improper > > (2) Make at least a superficial determination as to whether, if > you sent an error message by email, it would get delivered. > E.g., this would be a good time to check for the validity of the > domain in the MAIL FROM. > > (3) If the determination in (2) fails, either return a 5yz code > or just discard the message (others might disagree, but I would > contend that, if you can positively determine that you could not > deliver a mailed error message, even after retries, etc., you > are under no obligation to actually carry out the process). > > (4) Otherwise, generating a mail message might actually be a > better idea. > > Good luck. > > john > > Note 1: *Warning* you need to be a bit careful about those > emailed error messages. A few years ago, a popular spammer > trick was to send non-relay messages to an invalid address at a > site, putting a valid address of someone they wanted to reach in > the MAIL FROM field. This resulted in the victim getting mail > from an innocent bystander, even if that intermediate site had > good relay-blocking in place. > > > > --On Wednesday, December 05, 2001 5:32 PM -0500 "Schwartz, Jim" > <[EMAIL PROTECTED]> wrote: > > > John, > > > > Some mail related mailing lists recently had a discussion > > relating to this RFC. > > > > The heart of the matter comes from where the proper place is > > to test for relaying unwanted mail. > > During the SMTP session the client initiates the session as > > below > > > > S: 220 foo.com Simple Mail Transfer Service Ready > > C: EHLO bar.com > > S: 250-foo.com greets bar.com > > C: MAIL FROM:<[EMAIL PROTECTED]> > > S: 250 OK > > C: RCPT TO:<[EMAIL PROTECTED]> > > S: 250 OK > > > > Now in the above scenario, foo.com should not accept mail for > > somedomain.com. The question arises is at what point is it > > compliant to send an error back to the client that this server > > does not relay for somedomain.com. > > > > One side feels that at the end of the RCPT TO: command, the > > server should send back a 550 or 553 error code. > > > > Others are of the opinion that as rejecting at the Data > > command line with a 554 code is as compliant. > > > > Would it be possible for you to clarify this for us? > > > > Thank you. > > > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
