Hello Benoît How are your customers expressing that they want the message to be "rejected"? And who sets the rule conditions?
I was thinking that maybe the best way to design such system would be to convert the "reject" option to "delete this message automatically", but actually saving them in a er... "Autodeleted" folder where they can be browsed (for X days) along a reason on why it was deleted «This email from craigcockb...@example.com was automatically deleted by the user-defined filter "Profanity 101"». Given that you are rejecting after DATA, you could actually cheat a little and reject at SMTP level when there's only a single recipient, yet still show it there as deleted. As for the second problem, if you want to avoid backscatter, I would probably treat that as delivered to the local mailbox. The email arrived, it's the forwarding target what failed. So, if you are usually forwarding without keeping a copy, mails whose forwarding failed would stay on the inbox (else, they are already there). Then send a daily report to the user if there was any rejection for forwarded mail, notifying them that these N emails were not forwarded, since the email address he asked you to deliver to returned error foo. If the forwarding failed because the target server disliked the contents of such email, the notification will pass through alerting him, and it's up to the user to get a better configuration on that account (the old problem that if you wnat mail forwarded from A to B, B shall accept whatever A sends…). At least, the user can connect to the local mailbox and read it there. (This also has the nice benefit, that since you are sending absolutely no NDR to the original sender, you avoid leaking to them the email address to which is forwarded.) On the other hand, if the condition on the target email is more permanent (eg. they blacklisted your server), then the notification itself will pile up as not reported on tomorrow's. If the situation resolves automatically, the user will be notified. Else, there's little the server can do. The user must notice by himself that he hasn't received anything for a long time. When he logs in, the reason will be evident. Best regards Ángel Who enjoyed this thought process, but should try implementing something like this, too. _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
