Hi Michael > Kind of breaks the chain of responsibility though, so make sure you have > good logging of the event.
Logging alone is not good enough. Emails disappearing without a trace (for the recipient and sender) are always bad. Spam Mails usually are delivered to single recipients. So the head-ache happens with emails with a higher probability of being false positive legitimate emails (or recipients with reject all senders not in my whitelist setting). I don't want to be the one explaining to our customer why our system deleted his email after receiving it. > One of the things you didn't specify, is whether the content scanning > happens before end of DATA during SMTP, or after the SMTP MTA releases > the message for further processing. 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. > > But in high volume environments, you might settle on the logic. > > IF Single Recipient: > > > Recipient 1: Accept email and save to spam folder. > > Recipient 2: Reject spam mails. > > If Multiple Recipients: > > > Recipient 1: Accept email and save to spam folder. > > Recipient 2: Log and Drop.. Hmmm, no drop probably is not acceptable. But after pondering a bit more over the problem, what I think would probably be acceptable would be. Single recipient (most spam mails) process as we do now. 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. We could maybe solve the email forwarding problem in a similar way: * Single Recipient, do SRS Rewrite and chain in forwarding mailbox to limit 'delayed' bounces from the far side server. * 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. Have to think about it. Thank you all for your inputs. I think I got some inspiration on how to improve our platform. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
