|
Allan,
There's two ways Carbon Copies can work. The only thing that decides where an email is sent is the RCPT TO command (all the "CC:" headers are just that, headers that tell the email clients who the carbon copies were..)
1) The remote server initiates multiple SMTP transactions, all with separate HELO, MAIL FROM, RCPT TO, DATA sequences. Each individual one will have a separate RCPT TO recipient.
2) The remote server initiates a single SMTP transaction, with a single HELO, single MAIL FROM, and multiple consecutive RCPT TO commands, one for each recipient. After the last RCPT TO, the DATA command follows.
Yes, (2) is much more efficient, but there's many servers (inlcuding either RoadRunner or Yahoo, don't remember which) that uses (1).
If case (1), no problem, each mail has a separate recipient, so SpamFilter will only reject the one for which the recipient is blocked, the other one will be delivered if it passes the other filters. In case (2), the single transaction must be accepted (or rejected) globally for all RCPT TO's. Only at the end of the DATA message can we give them the "557 you can't send email", but if we do that, being a single email, the remote server will get an error for ALL recipients, even the good ones... There is not really a workaround here, and it's not really a bug. That single SMTP transaction needs to be rejected since one of the recipients is blacklisted, and this will cause all recipients to be rejected. There's a similar problem with "unfiltered addresses". If a spam email is sent to a user who is unfiltered, all the carbon copies sent using method (2) will still be delivered even if the other users are not whitelisted.
We have some ideas in mind not on how to completely solve this (RFCs were not written with SPAM in their minds...) but on how to limit the damage. It will take a few days to release a new build with the workarounds.
Roberto F.
LogSat Software
|