> SMTPACL is attempting to expand the use of mailets, which are already > heavily tied to SMTP processing, to a faster-fail environment.
Agreed. > > I would permit something like: > > > > <filter event="<event>"> > > </filter> > This implies there are more protocols and events than we actually have. No, just more events, e.g, connect, HELO, MAIL FROM, RCPT TO, DATA. I am not pre-supposing which ones are useful, or even for which ones we will implement a filter processor. I simply proposed a syntax that would permit a consistent treatment in the future. > > <filter event="<CONNECT>"> > > ... DNS RBL checks ... > > </filter> > This doesn't really relate to the mailet API, instead to our > server-container. Why? We already have a DNS RBL matcher which provides this functionality. This just permits it to provide it as a fast-fail at the earliest time. > Are we sure this is legal for a mail server to reject this way, > except temporarily such as responding to a DOS attack? Yes. See RFC 2821, section 3.1. We would return a 554 instead of a 220, return 503 for any commands other than QUIT, and wait for the client to issue a QUIT before disconnecting. And if one wants to configure one's system this way, and avoid being listed in the RFC ignorant RBL, you need to provide a very specific message regarding why you are rejecting the connection (http://www.rfc-ignorant.org/policy-postmaster.php). > > Leaving the choice of what and when to the mail admin, or possibly > > some future RFC. > Yes, this is about giving the mail admin choices of fast-fail. But > you're suggesting a solution to give RFC authors choices. No, as noted above, I am proposing a general syntax so that we have a consistent approach to whatever we need to do in response to evolving mail RFCs or user requirements. > > And, just as a talking point, I think that we may want a Mailet > > that explicitly provides a return code and message so that we > > can better collect statistics. > I believe that was addressed. If you mean to separate the two pieces > of data, then you've hardcoded responses to how SMTP handles responses. I am saying that there ARE cases where it is important in the protocol state machine to know what responses have come before. If you issue a 554 in response to a connection, it carries implications for future processing. I don't want to have to parse the response string. In any event, I don't see this as something we need to hash out right now. :-) --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
