Another possible solution is the option to allow - perhaps by server.tab variables - the postponing of any specific checks for rejection to the pre-data phase, and have a "policy" variable which simply holds a particular value for each recipient. As recipients are received by the mail server, their "policy" value is retrieved (perhaps from user.tab) and compared to existing recipients. If it's the same, the recipient is allowed. If it's not, the recipient is temp-failed (so that recipient will be retried in a later delivery attempt). Then, perhaps based on that policy value, the checks can be run or bypassed. Since the value contains for any given recipient would be opaque to the xmail code - it is simply checked for equality to existing recipients - it would need to be available to an external pre-data or post-data filter as a variable, which would allow the filter to perform or bypass checks, perhaps by returning a bitmasked value indicating which checks to allow.
I currently do something similar to this now (using some custom modifications to the xmail source code and external filters called by filters.pre-data.tab for the various checks I want done). It works pretty well, although it would probably be much faster if more of it were done in the xmail code. (BTW, no, I wouldn't be willing to share my mods - they are hacks in the worst sense of the word, and I'm not convinced my code would hold up in a heavy usage environment - plus they are very dependent on my external filter code, and they were based on the 1.21 code base and haven't been ported forward yet.) What I'm planning to do, if I ever get the time and energy, is to modify the xmail source code to allow both recipient policy settings and external "filter" calls at each stage (connection, HELO / EHLO, MAIL FROM, RCPT TO, DATA, and post-data), which will return values indicating what to do with the message (accept, reject immediately, postpone reject to pre-data, postpone reject to post-data, quarantine (meaning issue a fail to the sending server but keep a copy of the message for analysis), etc...). But this is going to take some doing, and I haven't had time yet (plus my C++ skills are not exactly the best in the world). Filip Supera wrote: > Sönke Ruempler a écrit : > > >>Yeah I guess he want's something receipient based, and not sender-based. >>ATM that's only possible with an own smtp filter and some own logic in >>it. :) > > > 1 possible solution would be domain based smtp.ipprop.tab instead of > server based. > - > 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] > > - 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]
