No matter what, even if you use a sophisticated MTA that can identify
separate spam rules for each recipient, typically not all spam checks
can occur until after the DATA stage. If you accept one for delivery,
you have to accept all, however since you don't want to create
backscatter (eg late bounce) for the users which have a 'reject' policy,
all you can do is drop the recipient from the delivery list, eg silently
'dropping' the message.
Kind of breaks the chain of responsibility though, so make sure you have
good logging of the event.
There ARE reported MTA's designed to 4xx when multiple recipients, and
one recipient has a 'reject', but frankly it doesn't buy you much, as
the retry will have the same message and same recipients, and/or it
slows the message down (or doesn't even get it) for a recipient that had
a different ruleset.
There are many experiments we looked at in the past, but in the end, if
a customers rules say they don't want a message, not even in their
quarantine, all you can do is drop it in the bit bucket..
But in todays's world, experience shows that (while it doesn't 'scrub'
the address from senders lists like a 5xx will) that in those cases
(multiple recipients) simply delivering it to his spam folder is your
best option.
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.
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..
So, until SMTP changes (eg, to send to only one RCPT, then content, then
ask to also deliver to other PPL for efficiency) we are stuck with a
non-perfect solution.
IMHO
On 2018-12-13 5:04 a.m., Benoit Panizzon wrote:
Hi
Thank you for the feedback.
So I wonder if others might have found a clever solution to that
problem.
Goal 1: Do NOT send a delayed bounce. (aka backscatter)
Goal 2: Never have an email 'disappear' in the system.
Goal 3: Respect Recipient's anti-spam settings.
Consider an email sent to two recipients. They have
different settings in their anti-spam rules, if the content scanning
determines the email is spam:
Recipient 1: Accept email and save to spam folder.
Recipient 2: Reject spam mails.
Thoughts:
If I accept the email, I could deliver it to the spambox of Recipient
1. but then I would need to either send a delayed bounce back regarding
Recipient 2 thus generating backscatter to potentially fake sender
addresses. Or I could silently drop the copy to recipient 2. But then if
that email was legitimate, my server just confirmed reception. Neither
sender nor recipient do know it was dropped. The email 'disappears'
from their point of perception. Something we definitely do not want.
So our best idea was to tempfail the subsequent recipients whose
settings which contradict the ones from the first recipient.
Any other ideas how this scenario could be solved?
Second problem:
If the recipients has a forwarding to an 'external' email account, we
want to use SRS to sign and rewrite the sender to pass SPF tests at the
destination server.
If the destination Server is rejecting reception (or generating a
delayed backscatter) we receive this to the signed sender SRS address,
extract the original sender from that address and forward that
backscatter to the original sender. So how do we solve Goal 1?
Easy, you also 'chain' the forwarding mailbox into the SRS Record. So
now we know which local email address forwarded the email to the
defunct destination, so we can disable local mailboxes with forwardings
to broken destinations (yes, of course there is a counter and self
correcting mechanisms, allowing a couple attempts etc, but mitigating a
'big' problem).
But now as you chain the forwarding address into the SRS record you
again get the same problem, you can only accept one single recipient to
do so. So we answer with 4XX if recipient count>1 for every local
mailbox with active forwarding.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
