On Wed, 14 Aug 2013, John Hardin wrote:
On Wed, 14 Aug 2013, Ted Mittelstaedt wrote:
1) WTF is pastebin? (not you, the other guy)
pastebin.com, a way to share files for public review. It's a far better way
to share spamples than posting them to the list, but be aware the files *do*
expire. Upload a spample to pastebin.com and post the URL to the list.
I take it by the:
a) lack of usable responses
b) responses NOT claiming this ISN'T a bug
c) responses tacitly acknowledging this is an "Oh crap they forgot about
BCCs when they wrote it but I don't have the balls to publicly call them
out on it like he did"
that I am dealing with a bona-fide Spamassassing design fuck-up, and in
summary if I'm going to continue to use spamass-milter that the option
all_spam_to is off the table.
I think this is happening because spamass-milter is passing the message to SA
before the MTA has split it up for delivery to individual local users. While
doing the latter is more resource-intensive, it allows per-user SA config and
message disposition (e.g. quarantine folders) and keeps things like
whitelists from leaking cross-user in the way you're seeing.
Unfortunately it appears spamass-milter is hardcoded to scan at that point in
the process. I don't think there's much SA can do about it.
It's not so much that spamass-milter is hardcoded, but the sendmail 'milter'
mechanism, by design' gets the message at the front-end, before any local
processing is done to it.
This gives the milters the ability to pre-process messages and modify them
so that all further processing is done with the modified message.
SA scans for whitelist addresses in a specific list of message headers; it's
likely spamass-milter is creating a pseudo-header[1] with the BCC recipients
for SA's use. Posting to pastebin the headers from a message improperly
whitelisted due to a BCC recipient might let us determine that.
No, spamass-milter does not create any BCC headers. It -does- syntesize a
'X-Envelope-To:' header in the message copy that it passes on to SA but
that added header is not passed back into the original mail stream.
[snip..]
Quite possibly, especially if spamass-milter is composing a pseudo-header
with the BCC addresses. But that's not something the SA team can do.
spamass-milter is a third-party tool that is not part of the SpamAssassin
project and is not shipped as part of the SpamAssassin install.
[1] I have not inspected the spamass-milter source code to verify this, but
this is pretty common practice in milters - for example, the local Received
header *must* be "forged" in this manner.
Adding a synthesized 'Received' header is a must, adding 'X-Envelope-*' headers
good practice but adding a 'Bcc:' header? never seen a milter do that.
Ted
On 8/14/2013 1:59 PM, Axb wrote:
On 08/14/2013 08:08 PM, Ted Mittelstaedt wrote:
> Hi All,
> > I'm having a lot of problem with spammers who are sending spams
with
> a To: of a user who is NOT in my all_spam_to list and a BCC: listing
> a user IN the all_spam_list. Usually the BCC's list multiple users,
> I guess on the theory that they are trying to hide which one it is.
> > The user gets the spam and it's got a score of -93 or some
> such but they don't understand why since they aren't in the all_spam_to
> list.
> > My thought is that this is a bug - SA should not be looking at the
> email addresses in the BCC to determine scoring adjustments for an
email
> message. So far the spammers haven't listed the abuse email address
> in the BCC but that is a natural one that almost always has to be in
> the all_spam_to list.
> > Suggestions?
tried splitting recipients before msg is sent thru SA?
With the -one- exception of an initial mail submission, any mail message
that contains multiple addresses in a "Bcc:" header is in violation of rfc-2821.
Most valid MTAs either completely strip out the Bcc: header or empty it.
If you find such in your MTA mail stream the answer is simple, either it's a
forgery or a borked MTA, so just trash the message, crash, & burn.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
