> 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.
Agreeing in principle to a recipients list is NOT the same as agreeing to deliver the message. That agreement only happens at such time as the server responds positively to the end of the data stream. > Be precise in what you send and generous in what you accept. Which is the underlying tenent of this RFC, and which you directly contradict in your following comments: > > 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"). As there is a contradiction within the RFC, until such time as it is amended to address that contraduction, is it not imperative that we DO practice the concept of "liberal in what you accept"? > 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. So I take it you are not in the "full disclosure" camp with regards tosecurity vulnerabilities? It strikes me that one of the greatest services that you could provide to the administrator community is to publish the methodology by which you test. The reasoning here is multifacited. First, there is no concise, cross-platform public repository of this information. Second, more people would and could accurately test their own systems, - I won't submit voluntarily to a scan from your or any other service as if perchance I am not relay-secure, I would rather fix it and test again than have to deal with removal from such a list. Third, this information would help educate newer mail administrators to understand the mechanisms behind relaying, and how to prevent it. My personal belief is that the UCE perpetuators are aware of every current relay technique - in fact I think its safe to say that they are more aware of the techniques than most administrators. Most vulnerabilities are found not by white hats looking for them, but by black hats who use what they find until such time as they are closed. > 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/ I'm not familiar with spews.org - I will check them out. ------------------------------------------------------ Roger D. Seielstad - MCSE MCT Senior Systems Administrator Peregrine Systems Atlanta, GA http://www.peregrine.com _________________________________________________________________ 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]
