You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2021/03/09 09:43:36 UTC
[Bug 7888] New: SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in
what it means
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Bug ID: 7888
Summary: SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in
what it means
Product: Spamassassin
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: byron@zoomedia.co.za
Target Milestone: Undefined
I'm managing a bulk email service for the company I work at and a recent change
to SpamAssassin has started flagging emails sent by our bulk-email solution
with 'RAND_MKTG_HEADER'. I can't find much about this on the internet other
than 'Has partially-randomized marketing/tracking header(s)'. The thing is, the
software doesn't randomize any of the marketing headers for the campaigns sent
with it, so I'm a bit confused as to the hows and whys and what I can do to fix
this issue.
Naturally campaigns IDs are randomized UIDs, that's the nature of indentifying
things uniquely. If anyone has any insight as to what this particular flag
entails and what I can do to fix the issue it would be GREATLY appreciated as
it's starting to impact our legitimate customers with delivery issues.
I just need an understanding of how this rule is implemented that I can
understand what it is I need to do on our software to prevent our mails from
getting flagged for now reason.
The headers as generated by the software for a test email was as follows:
Return-Path <bo...@reactivemail.co.za>
Received from node01.rdsmtp.co.za (node05.rdsmtp.co.za [102.222.20.123])
by inbound-smtp.eu-west-1.amazonaws.com with SMTP id
4uonu4k25fer8posk54lfdrj2rrr6a8t4chr7381 for allanb@glockapps.awsapps.com; Tue,
09 Mar 2021 07:59:08 +0000 (UTC)
Received-SPF pass (spfCheck: domain of reactivemail.co.za designates
102.222.20.123 as permitted sender) client-ip=102.222.20.123;
envelope-from=bounce@reactivemail.co.za; helo=node05.rdsmtp.co.za;
Authentication-Results amazonses.com; spf=pass (spfCheck: domain of
reactivemail.co.za designates 102.222.20.123 as permitted sender)
client-ip=102.222.20.123; envelope-from=bounce@reactivemail.co.za;
helo=node05.rdsmtp.co.za; dmarc=none header.from=zoomedia.co.za;
X-SES-RECEIPT
AEFBQUFBQUFBQUFGU0w2T2pLeEEvRmM0bzVkTjQzTTNlZ2NQZHpFMTcxNE0zM252d0lQS09xdGlDeWxoNmZ0TUx2SWJIczJONC9URHpOcjF6eE9jSnRaRmJhWUl6aU1QN2ZvQWR5RUtDczB3N3VaTWgzS05KVDh2UHZLMmRMZ3F4MUVyc1ZKMGM5YURLRG9mVnpYTGRCOXNSM0ZyWVlOcGVCN2txTCtqSGZyZHFzL1BqeVVMSWpxWE81MkoyRzBMNXB6ZEhyYXRyaEh3VDVDZWQyZHZ1ZmNQL0J6N1ZmUGp4VzF2M2JXS1VEMko3RXBqN0tPZmI5WlNtcHBzU01JbUQzNjdhYUZ3Vmc2M3ZHZUxLcCsvK2UrUlY2T1FPTjFGbStkZnRQbjFqMEs0S2o3SU5HWEZCbVE9PQ==
X-SES-DKIM-SIGNATURE a=rsa-sha256; q=dns/txt;
b=VXZhV4TYl1Qyaqw8fAWSV+lrpJkukBYYrRg2ZHmTwk6Q9OECnIt/TqRwp+9wAmfd25KFu2TIUfSe7zVEX+ZSpv79qh84+wTEh8eYWXS31sxsAR5JCyD8IJUKo1Qt0bS16QqAzmx5UXoGn+6obmMltz7GABl/6hSkLED5u1f7KuE=;
c=relaxed/simple; s=shh3fegwg5fppqsuzphvschd53n6ihuv; d=amazonses.com;
t=1615276751; v=1; bh=Mg5rJb3Fw4sZjqtrjW3+e/pHHQz+A3QFmtArIn+aRJs=;
h=From:To:Cc:Bcc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-SES-RECEIPT;
Received from app.reactivemail.co.za (unknown [129.232.154.87]) (using
TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client
certificate requested) (Authenticated sender: a22sv6v) by node01.rdsmtp.co.za
(Postfix) with ESMTPSA id 1E6F2406AFAD for <al...@glockapps.awsapps.com>; Tue,
9 Mar 2021 09:59:04 +0200 (SAST)
Message-ID <88...@reactivemail.co.za>
Date Tue, 09 Mar 2021 07:59:03 +0000
Subject This is Reactive Mail!
From ZooMedia (Pty) Ltd <su...@zoomedia.co.za>
Reply-To ZooMedia (Pty) Ltd <su...@zoomedia.co.za>
To "allanb@glockapps.awsapps.com" <al...@glockapps.awsapps.com>
MIME-Version 1.0
Content-Type multipart/alternative;
boundary="_=_swift_v4_1615276743_fa4eae3ba1192a96121b5cee055ac2ca_=_"
X-Sender bounce@reactivemail.co.za
X-Report-Abuse Please report abuse for this campaign here:
https://app.reactivemail.co.za/campaigns/eb698rlbz4057/report-abuse/kp906nfw2f946/qg5453nyx604b
X-Receiver allanb@glockapps.awsapps.com
X-Edjv-Tracking-Did 0
X-Edjv-Subscriber-Uid qg5453nyx604b
X-Edjv-Mailer SwiftMailer - 5.4.x
X-Edjv-EBS https://app.reactivemail.co.za/lists/block-address
X-Edjv-Delivery-Sid 2
X-Edjv-Customer-Uid qs001gtye8f14
X-Edjv-Customer-Gid 6
X-Edjv-Campaign-Uid eb698rlbz4057
Precedence bulk
List-Unsubscribe
<https://app.reactivemail.co.za/lists/kp906nfw2f946/unsubscribe/qg5453nyx604b/eb698rlbz4057/unsubscribe-direct?source=email-client-unsubscribe-button>,
<mailto:support@zoomedia.co.za?subject=Campaign-Uid:eb698rlbz4057 /
Subscriber-Uid:qg5453nyx604b - Unsubscribe request&body=Please unsubscribe me!>
List-Id kp906nfw2f946 <TEST ONLY>
Feedback-ID eb698rlbz4057:qg5453nyx604b:kp906nfw2f946:qs001gtye8f14
Content-Location
https://app.reactivemail.co.za/campaigns/eb698rlbz4057/web-version/qg5453nyx604b
Thanks in advance!
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #4 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to Giovanni Bechis from comment #3)
> For the records:
> I told him to ask on users@ or post here because it could be a bug in our
> rules.
I have asked on both so far, I've got a ton of people eating me alive right
now, so I really just want to know what I can do to at least mitigate the issue
for the time being. Our customers' mails are backing up and I've got an angry
mob I need to settle
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #6 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to RW from comment #5)
> 3 points does seem a bit extreme for a tracker.
>
> The rule is
>
>
> ALL =~
> /^X-(?:[a-z]{2}){1,2}-(?:EBS|(?:
> Tracking|Subscriber|Delivery|Customer|Campaign)-[DSU]?id):/ism
>
> Which matches the names of these header:
>
> X-Edjv-Customer-Uid, X-Edjv-Campaign-Uid, X-Edjv-EBS, X-Edjv-Tracking-Did,
> X-Edjv-Subscriber-Uid
I have temporary editing the code responsible for the tracking headers and
removed then entirely, hopefully this clears up the score a little, since we're
otherwise fine. Just getting hit hard by that one rule.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Loren Wilton <lw...@earthlink.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lwilton@earthlink.net
--- Comment #14 from Loren Wilton <lw...@earthlink.net> ---
>The rule is
>
>ALL =~
>/^X-(?:[a-z]{2}){1,2}-(?:EBS|(?:Tracking|Subscriber|Delivery|Customer|Campaign)->[DSU]?id):/ism
>
>Which matches the names of these header:
>
>X-Edjv-Customer-Uid, X-Edjv-Campaign-Uid, X-Edjv-EBS, X-Edjv-Tracking-Did,
>X-Edjv-Subscriber-Uid
Note the match part /(?:[a-z]{2}){1,2}/. This will match 2 or 4 letters
surrounded by dashes. If you have control over the header formatting, Change
Edjv to Edgvi or Edg or Ed1v or something like that, to break the 2 or 4
character pattern. Assuming those header formats are defined in a single place
in the software, they should continue to link in all the places used (unless
you need to fix some scanning patterns in the software also), so should
continue to perform their function, while avoiding this hit due to spammers
using the software.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #2 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to RW from comment #1)
> This is a bug tracker. You should take this question to the user mailing
> list.
Thanks, I will do so, I was specifically told to post my question here, but
feel free to delete it.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Benny Pedersen <me...@junc.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |me@junc.eu
--- Comment #13 from Benny Pedersen <me...@junc.eu> ---
its funny suggestions say user@ when debate from bugzilla goes to dev@ :=)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #1 from RW <rw...@googlemail.com> ---
This is a bug tracker. You should take this question to the user mailing list.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Giovanni Bechis <gi...@paclan.it> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |giovanni@paclan.it
--- Comment #3 from Giovanni Bechis <gi...@paclan.it> ---
For the records:
I told him to ask on users@ or post here because it could be a bug in our
rules.
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in
what it means
Posted by Michael Peddemors <mi...@linuxmagic.com>.
On 2021-03-09 6:32 p.m., bugzilla-daemon@spamassassin.apache.org wrote:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
>
> --- Comment #15 from John Hardin <jh...@impsec.org> ---
>> while the software is being used maliciously, it is commercial software
>> (https://www.mailwizz.com) and this rule would punish everyone who bought
>> the software, legitimate or otherwise.
>
> I was not aware of that, I'd assumed this was a service-based situation. Thanks
> for that information.
>
>> It simple suggests making the rules "non-keyed" i.e using just X- and
>> not X-xxx- I'm curious to know if this would work as they suggest though.
>
> That seems to me the best suggestion. Why they thought using randomly-named
> headers was a good idea is beyond me.
>
> Rather than taking the random bit completely out, though, I suggest changing
> the prefix to something usefully unique but not random, like "X-Reactivemail-"
> (your company name). If the software depends on those headers being unique to
> properly process bounces et. al., that should be sufficient.
>
>> The only exclusion is ...
>
> There are more now.
>
Ouch, this almost puts me in rant mode... Goes to what the definition of
'spam' is I guess, but let's just talk to the technical points here.
No, NEVER use a dynamic header name (eg keyed), use that in the header
data section. It isn't the intent, headers should be constructed with
the idea that they could <sic> go into a registry.
Even the use of X- headers is now dissuaded, albeit even our own systems
still use it, X- was meant to indicate an experimental header, before it
is ready to be published into a registry.
Having said that, all headers are a mess, with many vendors putting them
in willy nilly.. but dynamic headers ARE a no-no, and SHOULD get your
messages marked as more spammy, as usually the ONLY reason a person does
that is to try to get past spam filters.
dynamic header names goes against the spirit of email headers, and no
software should be promoting or using them.
You mentioned bulk email sending, you didn't of course mention whether
this is single opt-in, non-optin, or confirmed double opt-in.
Also, your software's use of:
Return-Path <bo...@reactivemail.co.za>
That will also be penalized.. Use the actual sender's email address, eg
the client.. that will make sure people can 'whitelist' the sender.
Just an FYI.. No one should use 'bounce' as an excuse any more, it
should be accept or reject.. otherwise it is back scatter..
It should not be about worrying about getting past spam filters, it
should be about worrying about getting into the mailboxes of people who
want the senders email.
Trust me your good clients will love it that both end users and system
administrators can more easily 'whitelist' emails from companies that
they want information from.
Otherwise the first time you have a bad client, everyone will treat all
your email the same..
While a '3' score might seem heavy handed for a 'tracker', it should be
heavy handed if some one is abusing the intent of what email headers
should be. (And there are MANY spammers using that technique of random
named headers)
--
"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.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #15 from John Hardin <jh...@impsec.org> ---
> while the software is being used maliciously, it is commercial software
> (https://www.mailwizz.com) and this rule would punish everyone who bought
> the software, legitimate or otherwise.
I was not aware of that, I'd assumed this was a service-based situation. Thanks
for that information.
> It simple suggests making the rules "non-keyed" i.e using just X- and
> not X-xxx- I'm curious to know if this would work as they suggest though.
That seems to me the best suggestion. Why they thought using randomly-named
headers was a good idea is beyond me.
Rather than taking the random bit completely out, though, I suggest changing
the prefix to something usefully unique but not random, like "X-Reactivemail-"
(your company name). If the software depends on those headers being unique to
properly process bounces et. al., that should be sufficient.
> The only exclusion is ...
There are more now.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #12 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to Byron Kleingeld from comment #11)
> (In reply to RW from comment #10)
> > (In reply to John Hardin from comment #7)
> >
> > > (In reply to RW from comment #5)
> > > > 3 points does seem a bit extreme for a tracker.
> > >
> > > That's based on such headers appearing in very little ham in our corpus. If
> > > the bulk mailer doing this was a widely-used legitimate service I'd expect
> > > to see more hammy instances of it. The scored rule does have exclusions for
> > > signs in the ham we do have,
> >
> > The only exclusion is "&& !__HAVE_BOUNCE_RELAYS". __HAVE_BOUNCE_RELAYS is
> > test for whether any bounce relays are configured in the VBounce plug. In
> > most set-ups it's unconditionally false.
> >
> >
> > > That is historically the
> > > kind of tactic used by spammers to avoid static pattern and checksum
> > > detection tools and to pollute spam signature databases,
> >
> > That's more to do with the body. I don't think there's anything of that sort
> > that would be affected by non-standard headers.
>
> I'll have to agree with this, while the software is being used maliciously,
> it is commercial software (https://www.mailwizz.com) and this rule would
> punish everyone who bought the software, legitimate or otherwise. I am
> forced to return those headers because the software's bounce handling and
> box monitoring features require them to function as it reads the values to
> automatically unsubscribe bouncing mails, or deadmail boxes, etc etc.
>
> I'm at a bit of an empasse now, we've taken the time to build the reputation
> of our servers, set up SPF and valid DKIM records and all the DNS fluff that
> goes around running an email marketing platform only to get punished because
> it's a "spammy platform" that we've heavily modified over the course of 2
> years of development.
>
> I'm open to suggestions though, while -2 spam score isn't a death sentence
> for our mailers and we're working with postmasters to get our mails properly
> routed and whilelisted and all that jazz (Effort I seriously doubt a group
> of spammers would go through). It just feels a bit depressing getting
> punished for using off-the-shelf commercial mass mailing software as a basis.
MailWizz has finally replied to my support request with a link to the
following:
https://kb.mailwizz.com/articles/low-score-in-spamassassin-because-of-the-rand_mktg_header-rule
It simple suggests making the rules "non-keyed" i.e using just X- and not
X-xxx- I'm curious to know if this would work as they suggest though.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Byron Kleingeld <by...@zoomedia.co.za> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |byron@zoomedia.co.za
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhardin@impsec.org
--- Comment #7 from John Hardin <jh...@impsec.org> ---
(In reply to Byron Kleingeld from comment #4)
> (In reply to Giovanni Bechis from comment #3)
> > For the records:
> > I told him to ask on users@ or post here because it could be a bug in our
> > rules.
>
> I have asked on both so far
I have seen no posts regarding this on the SpamAssassin Users mailing list, so
I'll respond here.
(In reply to RW from comment #5)
> 3 points does seem a bit extreme for a tracker.
That's based on such headers appearing in very little ham in our corpus. If the
bulk mailer doing this was a widely-used legitimate service I'd expect to see
more hammy instances of it. The scored rule does have exclusions for signs in
the ham we do have, and is not hitting any ham, and hits on
otherwise-very-low-scoring spam, so the rule's score is fairly high. It's not,
however, a poison pill.
> the software doesn't randomize any of the marketing headers for the campaigns sent with it
Such headers were fairly prevalent in a recent forged-sender-backscatter spam
campaign that impacted one of my domains. Across spams from different sources,
the headers *were* (apparently) random. That is historically the kind of tactic
used by spammers to avoid static pattern and checksum detection tools and to
pollute spam signature databases, and does not come across as something a
legitimate mass mailer would do.
X-Cjqp-Delivery-Sid: 1
X-Dsyh-Delivery-Sid: 1
X-Etxr-Delivery-Sid: 1
X-Fxyn-Delivery-Sid: 1
X-Hqve-Delivery-Sid: 85
X-Kqoy-Delivery-Sid: 1
X-Lkcl-Delivery-Sid: 1
X-Lonj-Delivery-Sid: 6
X-Mw-Delivery-Sid: 18
X-Mw-Delivery-Sid: 2
X-Mw-Delivery-Sid: 37
X-Mw-Delivery-Sid: 4
X-Mw-Delivery-Sid: 698
X-toys-en-Delivery-Sid: 41
X-Vtaf-Delivery-Sid: 2
X-Zvjg-Delivery-Sid: 23
They may instead be something like a key for the bulk service client's account.
If so, they chose a poor way to do it.
So part of the answer is: Byron, you're apparently using a bulk mailer service
that is being actively abused by spammers, and that's having a negative impact
on the reputation of your legitimate email. Work with your provider on that
part of the problem.
> Just getting hit hard by that one rule.
I have reduced the score limit to 2 points, and added some further exclusions
to the scored rule (which may not help in your case, it doesn't look like you
are doing any of the "hammy" things our ham samples do). These changes will
probably take overnight to take effect.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #9 from Byron Kleingeld <by...@zoomedia.co.za> ---
pardom my spelling and grammer, it has been a horridly long day and my brain is
fried...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #10 from RW <rw...@googlemail.com> ---
(In reply to John Hardin from comment #7)
> (In reply to RW from comment #5)
> > 3 points does seem a bit extreme for a tracker.
>
> That's based on such headers appearing in very little ham in our corpus. If
> the bulk mailer doing this was a widely-used legitimate service I'd expect
> to see more hammy instances of it. The scored rule does have exclusions for
> signs in the ham we do have,
The only exclusion is "&& !__HAVE_BOUNCE_RELAYS". __HAVE_BOUNCE_RELAYS is test
for whether any bounce relays are configured in the VBounce plug. In most
set-ups it's unconditionally false.
> That is historically the
> kind of tactic used by spammers to avoid static pattern and checksum
> detection tools and to pollute spam signature databases,
That's more to do with the body. I don't think there's anything of that sort
that would be affected by non-standard headers.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #5 from RW <rw...@googlemail.com> ---
3 points does seem a bit extreme for a tracker.
The rule is
ALL =~
/^X-(?:[a-z]{2}){1,2}-(?:EBS|(?:Tracking|Subscriber|Delivery|Customer|Campaign)-[DSU]?id):/ism
Which matches the names of these header:
X-Edjv-Customer-Uid, X-Edjv-Campaign-Uid, X-Edjv-EBS, X-Edjv-Tracking-Did,
X-Edjv-Subscriber-Uid
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |apache@hege.li
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Henrik Krohns <ap...@hege.li> ---
Closing stale and apparently resolved bug.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #11 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to RW from comment #10)
> (In reply to John Hardin from comment #7)
>
> > (In reply to RW from comment #5)
> > > 3 points does seem a bit extreme for a tracker.
> >
> > That's based on such headers appearing in very little ham in our corpus. If
> > the bulk mailer doing this was a widely-used legitimate service I'd expect
> > to see more hammy instances of it. The scored rule does have exclusions for
> > signs in the ham we do have,
>
> The only exclusion is "&& !__HAVE_BOUNCE_RELAYS". __HAVE_BOUNCE_RELAYS is
> test for whether any bounce relays are configured in the VBounce plug. In
> most set-ups it's unconditionally false.
>
>
> > That is historically the
> > kind of tactic used by spammers to avoid static pattern and checksum
> > detection tools and to pollute spam signature databases,
>
> That's more to do with the body. I don't think there's anything of that sort
> that would be affected by non-standard headers.
I'll have to agree with this, while the software is being used maliciously, it
is commercial software (https://www.mailwizz.com) and this rule would punish
everyone who bought the software, legitimate or otherwise. I am forced to
return those headers because the software's bounce handling and box monitoring
features require them to function as it reads the values to automatically
unsubscribe bouncing mails, or deadmail boxes, etc etc.
I'm at a bit of an empasse now, we've taken the time to build the reputation of
our servers, set up SPF and valid DKIM records and all the DNS fluff that goes
around running an email marketing platform only to get punished because it's a
"spammy platform" that we've heavily modified over the course of 2 years of
development.
I'm open to suggestions though, while -2 spam score isn't a death sentence for
our mailers and we're working with postmasters to get our mails properly routed
and whilelisted and all that jazz (Effort I seriously doubt a group of spammers
would go through). It just feels a bit depressing getting punished for using
off-the-shelf commercial mass mailing software as a basis.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7888] SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what
it means
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7888
--- Comment #8 from Byron Kleingeld <by...@zoomedia.co.za> ---
(In reply to John Hardin from comment #7)
> (In reply to Byron Kleingeld from comment #4)
> > (In reply to Giovanni Bechis from comment #3)
> > > For the records:
> > > I told him to ask on users@ or post here because it could be a bug in our
> > > rules.
> >
> > I have asked on both so far
>
> I have seen no posts regarding this on the SpamAssassin Users mailing list,
> so I'll respond here.
>
> (In reply to RW from comment #5)
> > 3 points does seem a bit extreme for a tracker.
>
> That's based on such headers appearing in very little ham in our corpus. If
> the bulk mailer doing this was a widely-used legitimate service I'd expect
> to see more hammy instances of it. The scored rule does have exclusions for
> signs in the ham we do have, and is not hitting any ham, and hits on
> otherwise-very-low-scoring spam, so the rule's score is fairly high. It's
> not, however, a poison pill.
>
> > the software doesn't randomize any of the marketing headers for the campaigns sent with it
>
> Such headers were fairly prevalent in a recent forged-sender-backscatter
> spam campaign that impacted one of my domains. Across spams from different
> sources, the headers *were* (apparently) random. That is historically the
> kind of tactic used by spammers to avoid static pattern and checksum
> detection tools and to pollute spam signature databases, and does not come
> across as something a legitimate mass mailer would do.
>
> X-Cjqp-Delivery-Sid: 1
> X-Dsyh-Delivery-Sid: 1
> X-Etxr-Delivery-Sid: 1
> X-Fxyn-Delivery-Sid: 1
> X-Hqve-Delivery-Sid: 85
> X-Kqoy-Delivery-Sid: 1
> X-Lkcl-Delivery-Sid: 1
> X-Lonj-Delivery-Sid: 6
> X-Mw-Delivery-Sid: 18
> X-Mw-Delivery-Sid: 2
> X-Mw-Delivery-Sid: 37
> X-Mw-Delivery-Sid: 4
> X-Mw-Delivery-Sid: 698
> X-toys-en-Delivery-Sid: 41
> X-Vtaf-Delivery-Sid: 2
> X-Zvjg-Delivery-Sid: 23
>
> They may instead be something like a key for the bulk service client's
> account. If so, they chose a poor way to do it.
>
> So part of the answer is: Byron, you're apparently using a bulk mailer
> service that is being actively abused by spammers, and that's having a
> negative impact on the reputation of your legitimate email. Work with your
> provider on that part of the problem.
>
> > Just getting hit hard by that one rule.
>
> I have reduced the score limit to 2 points, and added some further
> exclusions to the scored rule (which may not help in your case, it doesn't
> look like you are doing any of the "hammy" things our ham samples do). These
> changes will probably take overnight to take effect.
I appreciate the response, I might have fudged up the sending to the mailing
list, I'm not often exposing to fancy systems such as that. In the case of the
mailing provider, that would be the company I work for. I assume the bulk
mailing software we're using (albeit heavily modified from the original base
software) could potentially be used for illicit mailing. I had manually removed
those headers from the mailer code, but I am worried if there are other parts
of the software that might use those headers, like bounce handling and box
monitoring, regardless, knowing how the rules work now I can, if all else
fails, attempt to modify how those aspects of the software work and try to get
around the rules getting our mails falsely flagged. It's shame though, this
software is pretty damn good at what it does, but I can absolutely see it being
abused due to it's low upfront cost.
--
You are receiving this mail because:
You are the assignee for the bug.