SpamAssassin flag 'RAND_MKTG_HEADER' is unclear in what it means - email

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.
Thanks in advance!

It's likely caused by a custom X- header prefix, i.e. you have an X-something- prefix in your mailer software. If you happen to use Mailwizz, here is the solution: https://kb.mailwizz.com/articles/low-score-in-spamassassin-because-of-the-rand_mktg_header-rule/
You can essentially fix the problem by changing the custom header prefix to a traditional X- prefix.

Related

Surefire way to know if an email is in reply to an email my mail client sent

I'm looking for a way to know definitively if an email I receive is in response to a specific email I sent. I manually set the Message-Id of the outgoing message using make_msgid, store this value, and then check the In-Reply-To of an incoming email to determine if it is equal to the original Message-Id I sent.
This approach is basically what is suggested here in this very helpful answer by Mohammad Eghlima.
But I wonder if this approach is "foolproof" and if there is a better way to accomplish this? For example if there are some clients other than outlook, gmail etc. that do not follow this convention of setting In-Reply-To to the Message-Id of the original mail for replies, or if they set their own Message-Id for some reason (ex. Gmail does this if it determines the existing message id doesn't follow RFC standards)?
I've seen some other answers mention other potential methods to accomplish what I'm trying to do - for example, here but most of these questions/answers are from 10 years ago so I'm wondering if there is a better way to accomplish this now.
No, nothing is entirely foolproof. Junior PHP programmers write new email-sending code every day and none of it conforms to any particular set of conventions or RFCs. And then there's Microsoft and Google ... Oh, you are already familiar with them.
There have been no significant developments in email standardization on this particular front in the last decade, so advice from 10 years ago is by and large still relevant.
If anything, the field has been polarized by Microsoft and Google plunging ahead to "innovate" in various aspects of what may charitably be characterized as usability improvements over traditional email, but the motivation has often been to silo in users to prefer or be forced to use their solutions, not standardize anything.
(The efforts to improve e.g. email security through DMARC etc has been better coordinated and standardized.)
The post you link to basically summarizes the information from D. J. Bernstein's excellent email reference resource https://cr.yp.to/mail.html; see in particular the threading conventions at https://cr.yp.to/immhf/thread.html

PHPList Bounce Rules?

I'm trying to get PHPList 3.3.1 to process email bounces and to "unconfirm" or delete users based on email bounces to them. I have the following settings in my PHPList config file:
define ("MANUALLY_PROCESS_BOUNCES",1);
define('USE_ADVANCED_BOUNCEHANDLING',0);
$bounce_unsubscribe_threshold = 2;
I have "Processed Bounces" and PHPList dutifully reads the bounced emails, adds them to the database, and deletes the emails.
However, it doesn't seem to mark users as unsubscribed, even after 2 bounces.
Do I need to add advanced bounce rules? If so, can you provide me with a good basic list of rules to use?
I did try the "Generate Bounce Rules" option and it created 1100 rules (yes, one thousand one hundred rules) - yikes! Seems like there should be something like 5 or 10 rules that would cover most bounces.
Little help?
This is still a relatively undocumented part of phplist. We have a sophisticated list of regex expressions we use but currently not public.
I suggest you start here: PHPList Bounce Rules? to find expressions to track the kind of phrases you want to capture and also the doc itself includes some starting rules: https://www.phplist.org/manual/ch040_bounce-management.xhtml
What is not so documented, or I haven't found at least, is the differences between some of the actions you have available but with a bit of work and time you can fine tune based on your traffic and more important... your customers MTAs.
Further to this questions I started a thread on PHPlists forum than might be of help:
https://discuss.phplist.org/t/please-help-clarifying-advance-bounce-processing/4077/4
if you're still having difficulty with the rules. Be sure they are ACTIVE and not in the CANDIDATE section. Sometimes, with so many created rules the system won't let you just tag them all and change to ACTIVE as it freezes.
You can always go to your phplist database and use the following:
UPDATE `TABLEPREFIX_bounceregex` SET `status` = 'active'
Where TABLEPREFIX should be the same as yours. Hope it helps so many years later.
Consider, as well, installing the Housekeeping plugin » https://resources.phplist.com/plugin/housekeeping

Can I put star (★) in my email subject?

I got a request from my client that they want to add stars (★) to their email subject (They send these mails through the application we made as a part of bigger CRM for them).
I tried to send a test mail, and the email title is displayed nicely in my Gmail account, and I must agree with my client that it is eye catching, but what came to my mind is that this may be a spam magnet, so I googled about it but I can't find the actual "don't do this".
Generaly, my oppinion would be not to use it, but now I have to explain to the client why. My best explanation whould be there is a probability your emails will be treated as spam but I don't have the background for this statement.
Do you have any suggestions about what should I do?
The only information I could find is on the SpamAssassin page of how to avoid false positives. The only relevant part I found was this part.
Do not use "cute" spellings, Don't S.P.A.C.E out your words, don't put
str#nge |etters 0r characters into your emails.
SpamAssassin is a very widely used spam filtering tool. However, simply breaking one of the rules (strange characters) alone wouldn't get an email marked as spam. But combined with some other problems could lead to your email being considered spam. That being said, if your email is a completely legitimate business email, it's likely that few other rules are triggered, and using the special characters wouldn't create a huge problem. That being said, you should probably try out a couple test emails on SpamAssassin and a couple other spam filtering tools in order to come to a better conclusion on the emails you plan to send out.
Simply explain to your client as you have explained to SO: you stated that the star made it eye catching: this doesn't directly mean that it will be treated as spam, but you could explain how that concept COULD be considered spam.
If the star is part of their branding, however, this could be quite a nice way in which your client expresses themselves.
Spam emails are becoming more and more like what one would consider 'normal', so I think they have trial it internally, test the concept.
Talk it over with your client - there is going to be no basis in hard fact with things like this, purely social perception.
More and more retailers are using unicode symbols in their subject lines since a few months. Of course it's in order to gain more attention in cluttered inboxes. Until now, there has been absolutely no evidence that such symbols increase the likelihood of failing spam filter tests. However, keep in mind that rare symbols might not render (correctly) across all mail user agents. Especially keep an eye on Android and Blackberry smartphones, but also on Outlook. In addition, due to a Hotmail bug symbols will render much bigger in subect lines and in the email body within the web front end. In fact, they are beeing replaced by images. All in all, the star shouldn't make any problems. At least, if it's encoded correctly in the subject line. So, go for it.

Prevent mail beeing marked as spam

I'm wondering how to prevent my emails from my site being marked as spam?
I'm using sendmail.
I ran into this article the other day and it feels like a shame to hoard it:
How To Ensure Your E-mail Gets Delivered
It covers a good range of topics wrt. hard/soft bounces, limits, reverse-lookups, blacklists, etc. and gives recommendations for dealing with different situations.
Happy ... spamming? :)

How To Test Email Deliverability - % In Junk Folder

Does anyone know a good tool to test whether your emails are going into spam folders?
My web app generates emails to users, and I've been getting a lot of reports back from people saying "hey, no one ever responded to my message".
I have SPF rules in place and functioning correctly (email header shows an spf pass). I've also run my message through spam assassin and it scores very low.
Any other ideas?
To know if your email goes in the inbox, you need to get a metric called "Inbox Placement Rate". This indicator can be provided by Return Path, but it's quite expensive. If you're not sending huge volumes it might not worth it. The only way to measure the IPR is actually to have a certain number of test inboxes... In other words: the only way to chech that your email is not in the spam folder is to make the test and see what happen. There is not other magic solution and that's what Return Path is doing.
This means that when you hear about people claiming they have a 99% deliverability / delivery, it might be true be it just means that the email was "accepted" or "delivered" by the ISP. It's a lot, but it's not everything!
What you should do is the following: use an ESP focusing on deliverability. Personally I work for Mailjet. I believe it's the best value you can get: personalized DKIM and SPF are provided for free, you get the antispam scorings, the analytics, Ip reputation monitoring, throttling, etc. It's an all in one tool to avoid the headaches of optimizing yourself. It's more expensive that Amazon SES because you get a lot of added value services, but it has much lower prices than a lot of traditional ESPs!
Bottom line is: optimizing everything yourself is a full time job. Knowing exactly if an email is in the inbox or not will cost you a lot. The best way to proceed is to:
respect the best practices (opt in, not too much images, no red, etc.)
get some metrics such as open rates, click rates, delivery, etc. and watch their evolution over time. Any change from one sending to the other might be a signal for a problem you want to investigate.
Use a tool that takes care all the deliverability optimizations
Mailjet is cool because no matter which plan you pick, you get to use all the options. But if you want a full overview of what is existing, check out this comparison table:
http://socialcompare.com/en/comparison/transactional-emailing-providers-mailjet-sendgrid-critsend
If you're a perfectionist who wants to finetune the layout, how the emails are displayed etc. Check out Litmus, it's also a quite powerful tool!
http://litmus.com/
Simple answer: Use Mailgun!!!!
http://mailgun.net/
They will do all of your email deliverability and setup for you and give you a powerful API to build on! They are amazing. You'll never have to worry about domain keys or SPAM filtering again!
You should also check that your IP is not on any of major blacklists. dnsbl.info
This will at least give you an idea if you actually are getting flagged as spam.
For the past two years, we've used the service DeliveryMonitor.com. However, they've stopped accepting new applications which is a big red flag...
I'm currently evaluating the service from emailreach.com using their free trial
... We are now using DeliveryWatch.com with pertty good results thus far...