> The issue is that your testing methodology, specifically in requiring > relay denial prior to the DATA command, ignores both the spirit and the > letter of RFC 2821. While it is logical, and potentially beneficial, to > reject mail as early in the transaction as possible, there is no > requirement that said rejection should happen at a specific time within > the transaction, only that it happen prior to issuing acknowledgement of > receipt.
I can't agree with you there. RFC 2821 is clear (section 4.3.2, Specific Sequences) that there should only be a rejection after the DATA command for technical reasons. Rejection on Relay is a rejection for policy reasons, and as such, 550 or 553 should be issued after RCPT. Indeed, 550 and 553 may NOT be used after DATA. > As I am sure you are aware, an SMTP client maintains complete > responsibility for final delivery of the message until such time as an > SMTP server accepts that message for delivery - which RFC 2821 clearly > defines in Section 6.1: I agree. > Therefore, the server has the option to reject the message at any time > up to and including the response it returns the end of the data stream. Yes, if it must, it can close at any point for technical reasons. However, when it replies 250 to the recipients, it has agreed in principle, that there are no policy reasons to reject the mail. > Likewise, Section 4.2.5 clearly states the possibility of a mail server > responding to <CRLF>.<CRLF> with a permanent error (5yz) message: "When > an SMTP server returns a permanent error status (5yz) code after the > DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any > subsequent attempt to deliver that message." I concur. > Section 4.2.2 does imply that 550 or 553 would be the most correct > response when rejecting for anti-relay reasons. Section 4.3.2, however, > states "SMTP clients SHOULD, when possible, interpret only the first > digit of the reply and MUST be prepared to deal with unrecognized reply > codes by interpreting the first digit only." It can be inferred here > that ANY response of a permanent error (5yz) should be deemed acceptible > as evidence that the recipient will not accept the message, nor will it > accept responsibility for final delivery. Be precise in what you send and generous in what you accept. Again, I agree. However, 4.3.2 is clear that you cannot use a 553 or 550 rejection, a policy rejection, after accepting RCPT TO. > Furthermore, section 3.3 states "The DATA command can fail at only two > points in the protocol exchange." The first case is one in which a 554 > No Valid Recipients error is returned. The second case states "If the > verb is initially accepted and the 354 reply issued, the DATA command > should fail only if the mail transaction was incomplete (for example, no > recipients), or if resources were unavailable (including, of course, the > server unexpectedly becoming unavailable), or if the server determines > that the message should be rejected for policy or other reasons." As > denying relaying is a policy issue, this verbage unequivocally > invalidates your position that Mr. Schwartz's mail server is not RFC > compliant. In fact, it potentially invalidates your methodology with the > specific test being applied in this instance. Unfortunately, this is neatly contradicted by 4.2.3, where 554 is not listed as 'no valid recipients, but as Transaction failed (Or, in the case of a connection opening response, "No SMTP service here"). 554 is a technical rejection, not a policy one. > As the postmaster for multiple domains, I applaud almost every effort to > combat UCE, including up to date lists of known open relays. However, > your site (http://orbz.gst-group.co.uk/) fails to list any of the > criteria by which you measure mail systems. By publicising that > information, you would be doing a great service to administrators in > giving us the tools to more quickly diagnose and close open relay > conditions on our servers. By giving such information, I also potentially allow thieves to find new loopholes to get themselves open relays that apparently meet my criteria to remain unlisted. I have to balance that dilemma on a daily basis; some people get caught in the crossfire. Thank you for your general, if not specific support, however. > As a potential consumer of the information contained within your > database, I cannot, in good conscience, actually use nor recoomend your > database, as I have no concrete evidence of the requirements for both > inclusion and removal from your database. Without that information, the > appearance is that the list might not create a level playing field. That > would place me in a tenuous position at best for any administrator. I understand and sympathise with your situation. Some people have decided they can trust ORB UK, others that they cannot. I do not suggest that anyone uses ORB UK on it's own. Personally, I use SPEWS http://spews.org/ -- Dr Paul Cummins - Internet Engineer | /"\ ASCII RIBBON Tel: 07021 117179 Fax: 07092 105150 + \ / CAMPAIGN Email: [EMAIL PROTECTED] | X AGAINST HTML MAIL | / \ AND POSTINGS _________________________________________________________________ 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]
