I see .. reading incoming DATA (including the header) and passing control to an extenal thread while buiffers are still receiving can be tricky. YOu're right. this one should be skipped and filtes should generally be implemented after each server reply, except data:
EHLO --> AFTER_EHLO MAIL FROM: ... --> AFTER_MAIL_FROM RCPT TO: ... --> AFTER_RCPT_TO DATA From: ... To: ... .. .. .. Genrally, filters must not consume more time than a return from a subroutine, which checks if a filter is plugged in. Filters should also be able to overwrite XMail's resonses. Davide, what do you think about that ? --Harald > I belive the header can better be handled with standard > filters since it is already implimented there anyway. Plus, > that is asking the server to fire a separate thread to handle > the filter, while still receiving DATA (which in most cases > will finish long before any script fully loads and has a > chance to react, and it is inaapropriate for the receiving > MTA to end the DATA stream), then just send an error at the > end of the DATA, saved nothing except a rejection to the > other MTA. I do like the AFTER_MAIL_FROM and AFTER_RCPT_TO > though, an AFTER_EHLO would be great too for EHLO/HELO > checks. Something to turn all checks off for proper SMTP_Auth > responses, would also be nice, or even simpler, a variable to > pass to filters @@SMTP_AUTH, with auth info (user is authed, > null if not, or something like that) so filters can be > bypassed selectively. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
