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.
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: "When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA)." 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. 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." 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. 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. 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. 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. Roger ------------------------------------------------------ Roger D. Seielstad Senior Systems Administrator Peregrine Systems Atlanta, GA http://www.peregrine.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 04, 2001 11:06 AM > To: Exchange Discussions > Cc: [EMAIL PROTECTED] > Subject: Re: ORB UK - cross post - long > > > > Note that relays are specifically mentioned in 2821. In the > discussion > > of relaying the bottom line is that a relay is not expected > to do much > > of anything at all, though it _should_ do xyz and _may_ do abc. > > Agreed. > > > What he should be testing on is the return of the NDR. > > No. There are three things specifically tested for. > > 1) Ability to Relay. This uses 19 different tests, hacks and > back doors. I > don;t propose explaining all of them here. > > 2) RFC Compliance. Rejection of relay without NDR. > > 3) RFC compliance. Is postmaster and abuse accepted by the server. > > If the server fails on any one of these tests it is, or > remains, listed. > > -- > 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] > _________________________________________________________________ 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]
