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]

Reply via email to