I may be wrong about this, but I imagine it wouldn't be at all easy to do.
By the time instructions in a user-space .courier file are processed, I
would assume the message has already been accepted for delivery, and the
best that can be done is to issue a DSN and email it back to the originating
system.
Hi Lindsay,
Yeah, I'm not sure if it's doable or not.
I could see a hypothetically implementation -- accept message for delivery, fork child to run delivery, wait for child's exit code, and the based on that exit value return to the smtp sender an appropriate status. Just because it's been accepted locally for delivery doesn't mean the sender has to be told. Of course, I have no idea what the current architecture would allow for, but if it were relatively easy to do, it would be terribly useful. If there was a soft-error on user delivery, I'd want the smtp sender to hear that it was accepted.
I could see there being some time-out conditions; maybe wait for 5-15 seconds for child process to return and if it's not returned by then, tell the smtp sender it was accepted, so as to prevent the smtp server from clogging up. The goal here is to prevent Courier from generating DSNs to forged from addresses, without doing callback verification in the first place, so that our postmaster boxes don't fill up with double bounces.
I suppose there is a second problem which is probably fatal: if the inbound message is destined for two local users, and one accepts it and the other hard-fails it, it's unclear what the semantics should be.
best, Jeff
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
