> >> I believe it's because that's what the SMTP RFCs require. Once the > >> receiving server sends the OK send data acknowledgement it can't return > >> a 4xx temp error. It must either reject the message or accept it for > >> delivery. Yeah, it sucks but that's the way it is... > > > > AOL does it! If your IP happens to be on one of their blacklists and you > > try to email an AOL subscriber, you don't get an error until you've > > completed the data section of your email and then the AOL mail server > > says "421 SERVICE NOT AVAILABLE". > > I'm sorry... Did you really start an argument with the words "AOL does > it!"!? Yes, I have reached the end of the internet... :-) Honestly, I > don't know and I don't have time to dig through the RFCs right now (nor do > I desire the headache I get when read RFCs...) Sam could say better why > 4xx errors aren't possible with .smtpfilter.
I just looked through RFC 2821, which I believe is the current SMTP specification. As far as I can tell, an SMTP server is not prohibited from returning a 4xx temporary error code at the completion of the DATA phase. RFC2821 does say the following about the DATA phase: - If the SMTP server returns a 2xx response to indicate acceptance of the message, it accepts responsibility for delivering it (making a reasonable number of retries to get past temporary local error conditions) or returning "appropriate notification" to the sender if delivery can't be accomplished - If the SMTP server returns a 5xx response to indicate a permanent error, it MUST NOT make any further attempts to deliver the message itself. It doesn't say anything one way or ther other (in section 4.2.5 at least) as to whether 4xx temporary errors are allowed, or forbidden. Reading between the lines, though: there is a temporary error 452 which means "Requested action not taken: insufficient system storage." This is a type of error which could reasonably be expected to occur during the DATA phase, if a very large message were submitted by an SMTP client. There's also a 451 "requested action aborted, local error in processing", which might be the sort of thing that could occur during the DATA phase. Unless I'm missing something, a 45x temporary-error reply at the completion of the DATA phase is both reasonable and acceptable under RFC 2821. If that is indeed the case, then I would appeal to Sam to roll a change into the next version of Courier to actually permit smtpfilter scripts to echo back a 45x error code, just as the rcptfilter scripts can already do. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
