On 12/13/2018 08:44 AM, Benoit Panizzon wrote:
I don't want to be the one explaining to our customer why our system deleted his email after receiving it.
I would much rather explain why an extra message was put into the spam folder than explain why we didn't deliver a message.
Content filtering happens between the '.' after Signaling the End of DATA. So we can reject the content within the SMTP session with an appropriate message if needed.
:-)
Yes I know, very resource intensive, but the only way to do it properly.
Agreed.
Multiple recipients (less likely spam) accept the email. Deliver to those which have spam-filtering disabled. Deliver to Spam-Filter of those who have spam-filtering enabled and maybe add a text file explaining why this email has been delivered.
As a recipient, I would prefer that the spam message not be modified. So if you add a message, I'd like it to be a new email with the message and the original spam as an message/rfc822 attachment. I'd also be happy with the original message in the spam folder plus a reply addressed to me with an explanation of why the known spam was delivered despite knowing it was spam. (Ideally in such a way as the note is threaded to the original spam, In-Reply-To: / References:)
* Multiple Recipients, do SRS Rewrite sender, but do NOT chain in forwarding mailbox. This allows us to accept all recipients at once, but in case the forwarding does not work, we don not have a way to extract the forwarding mailbox information from the 'late' bounce we receive and disable forwarding if bounces cross a threshold.
Where and how are you doing your forwarding and SRS rewriting? Are you doing it at the MTA level, via .forward / virtusertable redirection? Or are you doing it via LDA (procmail, maildrop, etc)? I would think this would impact if you re-send the same message to multiple recipients once (using SMTP's traditional optimization of multiple recipients per single copy) or multiple messages.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
