Chris Lewis wrote:
Jared Johnson wrote:
Peter J. Holzer wrote:
That's why I wrote cf_wrapper (it's in the contrib directory), which
checks the results for all recipients and returns a temporary error when
they don't agree - when the client resends the message, it can "split"
them into two groups with consistent responses.
Who is "the client" here? The remote mail server? Won't this break
when remote mail servers decide to just re-attempt the same message
with the same recipients?
If the sender gets a tempfail for anything other than RCPT TO, I would
not expect the sender to split the resend, in fact, it's highly
unlikely. Which means in particular you can't make this work for
anything that involves checking DATA (eg: spamassassin/bayes/string
matching etc).
On a multiple recipient email once you hit DATA, where some of the
per-recipient filters say "yay" and others "nay", the only safe thing
you can do is blackhole the emails for the "nay"s, and let the "yay"s
thru. Can't reject, and bouncing the nays is backscatter (part of the
spam problem, not the spam solution). And I really hate blackholing -
reject is mandatory.
We sidestep by not doing per-user filter selection. Except for the
recipient "accept everything" whitelists - we only have 2 of those, and
they're a HUGE pain in the butt, because up until recently, if you CC'd
a whitelisted address, it got thru to all of the other recipients.
We have subsequently changed things so that the recipient whitelist (for
the account that's usually CC'd in multi-rcptto spams) is ignored if
there are any other addresses in the CC/TO list.
Sorry, that should be "if there are any other addresses in the RCPT TO
list". Which means if there's any addresses here in addition to the
whitelisted address, you takes your chances with the filtering - if the
filtering fires, nobody gets it.
