You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ted Mittelstaedt <te...@ipinc.net> on 2013/08/14 20:08:44 UTC
Problems with BCCing from spammers
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?
Ted
Re: Problems with BCCing from spammers
Posted by Benny Pedersen <me...@junc.eu>.
Ted Mittelstaedt skrev den 2013-08-14 20:08:
> Suggestions?
pastebin ?
only local mta sees bcc, when its sent its removed
Re: Problems with BCCing from spammers
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2013-08-14 at 15:20 -0700, Ted Mittelstaedt wrote:
> 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.
Just 4 hours in and you're going off like that?
What do you expect by a volunteer driven Open Source project? 24/7
support with a guaranteed reaction time of less than an hour?
> That's all I needed to know. If I'm wrong, and it's me that is doing
> something wrong with the option, then tell me. But in the absence of
> that, I will have to assume that I am correct, that this is a design
> oversight/cock-up/ass-scratcher and deal with it.
You're free to assume whatever floats your boat. You're still wrong,
though, even if you *assume* you are right.
It is also pretty obvious you didn't bother to read the docs [1] before
going all ranty.
> Coolest would be someone posting a patch to spamass-milter to the list
> that would add "ignore BCC in header" as an option, just like someone
> posted a patch a few years ago for spamass-milter that adds an
> authentication bypass. (which has yet to be added to the spamassassin
> distro, even though many Linux/Unix distros now include it)
spamass-milter is NOT part of SA.
Thus, the patch you're referring to cannot and will never be added to
SA. No matter how hard you try to blame SA for not including the
spamass-milter patch...
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Problems with BCCing from spammers
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 8/15/2013 12:29 AM, Axb wrote:
> On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
>>>>
>>>> Suggestions?
>
> http://www.snertsoft.com/sendmail/milter-spamc/
>
>
> Spam:recipient-address value * (FRIEND or HATER are recognised)
> Spam:recipient-domain value * (FRIEND or HATER are recognised)
> Spam:recipient@ value * (FRIEND or HATER are recognised)
The problem with that one is that it has no understanding of
authenticated SMTP
Only 1 of my mailservers has the sender and recipients split, I have
several other mailservers that receive mail for users and act as
outbound relays as well. The users are using suth-smtp from all over
the place not from a defined set of subnets, and I have to make sure
that SA is not run on email that comes from a user to be relayed out.
The authenticated SMTP patch for spamass-milter might be able to
be modified for this one but I'm not a good enough C programmer to
do it.
Ted
Re: Problems with BCCing from spammers
Posted by Axb <ax...@gmail.com>.
On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
>>>
>>> Suggestions?
http://www.snertsoft.com/sendmail/milter-spamc/
Spam:recipient-address value * (FRIEND or HATER are recognised)
Spam:recipient-domain value * (FRIEND or HATER are recognised)
Spam:recipient@ value * (FRIEND or HATER are recognised)
Re: Problems with BCCing from spammers
Posted by John Hardin <jh...@impsec.org>.
On Wed, 14 Aug 2013, David B Funk wrote:
> On Wed, 14 Aug 2013, John Hardin wrote:
>
>> On Wed, 14 Aug 2013, Ted Mittelstaedt wrote:
{snip}
>> 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.
Ah, ok. It's been a good many years since I looked at the milter API and I
had the impression there were multiple points in the process where it
could hook in.
>> 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..]
Does the generated X-Envelope-To: header include the BCC recipients?
>> 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.
Even if it did, that wouldn't explain the behavior. The SA whitelist isn't
looking for a Bcc: header (or any variant); it *is*, however, looking for
X-Envelope-To:.
The only way I can see to explain the reported behavior is if
spamass-milter was including BCC recipients in the generated
X-Envelope-To: header or one of the other recipient headers that SA
whitelist checks - see "perldoc Mail::SpamAssassin::Conf".
>>
>> > 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.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Of the twenty-two civilizations that have appeared in history,
nineteen of them collapsed when they reached the moral state the
United States is in now. -- Arnold Toynbee
-----------------------------------------------------------------------
Tomorrow: the 68th anniversary of the end of World War II
Re: Problems with BCCing from spammers
Posted by David B Funk <db...@engineering.uiowa.edu>.
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{
Re: Problems with BCCing from spammers
Posted by John Hardin <jh...@impsec.org>.
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.
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.
It's also possible that spamass-milter is not retaining that pseudo-header
after the scan, in which case you'd have to do some debugging or review
the spamass-milter code to see if that's indeed what's happening. But I
think that's what's happening, as SA has nowhere to get the BCC recipients
apart from the headers in the message it's been given to scan.
You might consider changing the glue to be on the delivery side of your
MTA, e.g. using procmail.
> No, I'm not going to tear apart the server and replace spamass-milter
> with something else. Not unless there's something else out there that
> is simple and doesn't require 600 dependent Perl modules (like mailscanner)
> and run like a 15 year old dog in the middle of August.
> (also like mailscanner)
Procmail is simple if all you're going to do with it is call SA at
delivery time. There may be some other lightweight delivery-time glue
utilities that I'm not aware of which somebody else here may suggest.
> Coolest would be someone posting a patch to spamass-milter to the list that
> would add "ignore BCC in header" as an option, just like someone
> posted a patch a few years ago for spamass-milter that adds an authentication
> bypass. (which has yet to be added to the spamassassin
> distro, even though many Linux/Unix distros now include it)
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.
> 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?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
North Korea: the only country in the world where people would risk
execution to flee to communist China. -- Ride Fast
-----------------------------------------------------------------------
Tomorrow: the 68th anniversary of the end of World War II
Re: Problems with BCCing from spammers
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 8/15/2013 9:38 AM, Matus UHLAR - fantomas wrote:
> On 14.08.13 15:20, Ted Mittelstaedt wrote:
>> I am using spamass-milter to process received mail.
>
> do you use "-u user" option? spamas-milter uses that user's config when the
> mail goes to multiple recipients. Isn't that user by any chance the one in
> all_spam_to list?
>
None of the users have individual configs, this is a mailserver
that does not store configuration data on a per-user basis, thus that
option does not apply.
> I guess if you don't specify the -u option, user "nobody" is used.
>
actually it's user root. It's a potato/potahto argument as to whether
to modify local.cf or a config in the root user, the end result is a
single global config.
>> If the option was supposed to process BCC also why wasn't it called
>> all_spam_to_both_to_and_bcc?
>
> I strongly doubt that any spam software does use Bcc:
> Bcc: is for MTAs that need to specify envelope users that do not go to the
> headers.
>
spamass-milter isn't a spam software it is a milter that calls spam
software. As David and John already discussed the way this appears to
be happening is that spamass-milter is parsing the users in the BCC:
header (which as you stated, shouldn't exist in an incoming email - but
it does - since that email is a piece of spam generated by some spammers
program) and passing those to spamassassin, which is seeing that one of
those users is listed in the all_spam_to configuration, and assigning
a -100 score, which is then essentially invalidating spamassassin's scoring.
Or, something like that - if I'm understanding the discussion properly.
Ted
Re: Problems with BCCing from spammers
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 14.08.13 15:20, Ted Mittelstaedt wrote:
>I am using spamass-milter to process received mail.
do you use "-u user" option? spamas-milter uses that user's config when the
mail goes to multiple recipients. Isn't that user by any chance the one in
all_spam_to list?
I guess if you don't specify the -u option, user "nobody" is used.
>If the option was supposed to process BCC also why wasn't it called
>all_spam_to_both_to_and_bcc?
I strongly doubt that any spam software does use Bcc:
Bcc: is for MTAs that need to specify envelope users that do not go to the
headers.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."
Re: Problems with BCCing from spammers
Posted by John Hardin <jh...@impsec.org>.
On Thu, 15 Aug 2013, Ted Mittelstaedt wrote:
> On 8/15/2013 12:14 AM, Axb wrote:
>> On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
>>
>> > I take it by the:
>> >
>> > a) lack of usable responses
>> > b) responses NOT claiming this ISN'T a bug
>>
>> it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
>> Your glue (hack) or MTA (best) should do this.
>
> It IS a bug since the software is not acting according to how it's
> documented or expected. That is the definition of a software bug.
SA only has the message headers to work with; *something else* has to put
the complete envelope recipient list into the headers for SA to be able
to see the BCC recipients.
If the glue is putting BCC recipients into a header that SA is documented
as checking for whitelisting, then it's *not SAs fault* that whitelisting
a BCC recipient affects an exposed recipient.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Windows and its users got mentioned at home today, after my wife the
psych major brought up Seligman's theory of "learned helplessness."
-- Dan Birchall in a.s.r
-----------------------------------------------------------------------
Today: the 68th anniversary of the end of World War II
Re: Problems with BCCing from spammers
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2013-08-15 at 09:53 -0700, Ted Mittelstaedt wrote:
> > it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
> > Your glue (hack) or MTA (best) should do this.
>
> It IS a bug since the software is not acting according to how it's
> documented or expected. That is the definition of a software bug.
>
> You can argue that it's a documentation bug and I might agree but it's
> still a bug
See the M::SA::Conf [1] docs, option whitelist_to. The expected behavior
and headers considered are clearly listed.
Please show some evidence, that SA is acting in violation to its
documentation, and that none of the listed headers contain an address in
your whitelist_to / all_spam_to configuration.
> An option stating "all_spam_to" followed by the email address of the
^^^
> RECIPIENT is basically stating that ONLY mail sent TO the recipient will
> be exempted.
Let me re-emphasize that: "THE recipient". Who is "the" recipient of a
message with multiple recipients? At which point is it "the" recipient,
before or after local alias expansion?
Regardless, the whitelist_to option is not about THE recipient, but A
recipient. The first sentence of documentation shows this:
"If the given address appears as a recipient in the message headers
(Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be
whitelisted."
> It would be better to have the option
>
> "all_spam_to_envelope_recipient"
Patches accepted.
> with the explanation that the recipient is who is being passed on the
> envelope To: not the To: in the header, or something like that, but
> the option as it stands implies the To: in the header, and that
> implication should be disabused in the documentation for the config
> file, at the very least.
It only implies (referring exclusively to) the To header, if one fails
to read the documentation -- absolutely clearly listing 12 headers.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Problems with BCCing from spammers
Posted by Daniel McDonald <da...@austinenergy.com>.
On 8/15/13 11:53 AM, "Ted Mittelstaedt" <te...@ipinc.net> wrote:
> On 8/15/2013 12:14 AM, Axb wrote:
>> On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
>>
>>> I take it by the:
>>>
>>> a) lack of usable responses
>>> b) responses NOT claiming this ISN'T a bug
>>
>> it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
>> Your glue (hack) or MTA (best) should do this.
>>
>
> It IS a bug since the software is not acting according to how it's
> documented or expected. That is the definition of a software bug.
>
> You can argue that it's a documentation bug and I might agree but it's
> still a bug
The wiki is reasonably clear that various headers are searched:
http://wiki.apache.org/spamassassin/AllSpamToFiltering
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: Problems with BCCing from spammers
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 8/15/2013 12:14 AM, Axb wrote:
> On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
>
>> I take it by the:
>>
>> a) lack of usable responses
>> b) responses NOT claiming this ISN'T a bug
>
> it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
> Your glue (hack) or MTA (best) should do this.
>
It IS a bug since the software is not acting according to how it's
documented or expected. That is the definition of a software bug.
You can argue that it's a documentation bug and I might agree but it's
still a bug
An option stating "all_spam_to" followed by the email address of the
RECIPIENT is basically stating that ONLY mail sent TO the recipient will
be exempted.
It would be better to have the option
"all_spam_to_envelope_recipient"
with the explanation that the recipient is who is being passed on the
envelope To: not the To: in the header, or something like that, but
the option as it stands implies the To: in the header, and that
implication should be disabused in the documentation for the config
file, at the very least.
Ted
>
>
Re: Problems with BCCing from spammers
Posted by Axb <ax...@gmail.com>.
On 08/15/2013 12:20 AM, Ted Mittelstaedt wrote:
> I take it by the:
>
> a) lack of usable responses
> b) responses NOT claiming this ISN'T a bug
it is *not* a bug. It's not SA's task to split a msg to multiple rcpts.
Your glue (hack) or MTA (best) should do this.
Re: Problems with BCCing from spammers
Posted by Ted Mittelstaedt <te...@ipinc.net>.
1) WTF is pastebin? (not you, the other guy)
2) This is mail received from the Internet for users on the mailserver.
Users on the mailserver transmit mail from their mail clients through a
completely different server
I am using spamass-milter to process received mail.
This is a Sendmail server. It's spam
processing is with 100% Spamassassin software. Spamassassin is being
called by software included with spamassassin.
Now,
If the option was supposed to process BCC also why wasn't it called
all_spam_to_both_to_and_bcc?
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.
That's all I needed to know. If I'm wrong, and it's me that is doing
something wrong with the option, then tell me. But in the absence of
that, I will have to assume that I am correct, that this is a design
oversight/cock-up/ass-scratcher and deal with it.
And, of course, be on notice that the spammers out there have figured
this one out and are actively exploiting it now. So everyone else
using spamass-milter is in the same boat. Maybe there should be
at lease a hashtag comment in the local.cf file so anyone else
with the same problem isn't wasting time with it?
No, I'm not going to tear apart the server and replace spamass-milter
with something else. Not unless there's something else out there that
is simple and doesn't require 600 dependent Perl modules (like
mailscanner) and run like a 15 year old dog in the middle of August.
(also like mailscanner)
Coolest would be someone posting a patch to spamass-milter to the list
that would add "ignore BCC in header" as an option, just like someone
posted a patch a few years ago for spamass-milter that adds an
authentication bypass. (which has yet to be added to the spamassassin
distro, even though many Linux/Unix distros now include it)
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?
>
Re: Problems with BCCing from spammers
Posted by Axb <ax...@gmail.com>.
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?