# Are all official Jolla mails destined for the spam folder? [too localized]

It's bugged me for a long time now that all official mails from Jolla end up in my spam folder. I can handle the situation for myself, but I'm concerned a lot of customers miss important news because of this. So my question is: Do other users of TJC experience the same? Does anyone have an idea what exactly triggers the spam filter in Jolla mails?

Here's a few facts as background information:

• I use my access provider's standard mail server and their server-side spam filtering with no custom rules or black-/white-listing
• Server uses SpamAssassin, but I don't have access to the exact configuration
• Spam filtering works excellent normally; it protects me from Nigerian millionaires and open-minded teen girls, but lets all the ham pass
• Mails from campaigns@jolla.com (where OS update notifications come from for example) regularly end up with something like
X-Spam-Status: Yes, hits=9.9 required=5.5, spamd 9.9(1)
Mails from no-reply@jolla.com (which include shipping confirmations) have a lower score (around 5.5) and sometimes even pass, but are also at risk
• I remember having had a similar problem over 1-2 years ago with mails that clearly were not spam, but got trapped in the server's filter. They were from a site that also used mailchimp, as does Jolla.

I'm aware that this is not a classic "question about Jolla or Sailfish", but where else would I find as many recipients of mails sent from campaigns@jolla.com? The aim would be to check if I'm the only one who finds them all in the spam folder (then it's my problem and I'm fine) or if this is a more general thing Jolla should do something about. (Also, just out of curiosity, I'd be interested to know which rules exactly could be triggered by mails like those about the OS updates.)

edit retag reopen delete

### The question has been closed for the following reason "too localized"by ossi1967 close date 2015-01-11 16:39:46.298396

1

It sounds like they have their SpamAssassin configured weirdly. Have a look at the raw headers and there may be a block like this...

 Content analysis details: (-1.9 points, 5.0 required)

  pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay
domain
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 HTML_MESSAGE           BODY: HTML included in message
0.0 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 chars
0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
X-Spam-Flag: NO


That might give you a better idea at which rule(s) are being tripped by your host. You may also be able to whitelist @jolla.com in your hosting panel or ask your host to do it for you.

( 2015-01-08 18:05:46 +0300 )edit

Got no problem with spam filtering Jolla Mails. I use the serverside spam prptection from Provider but there weren't any mails from Jolla in Spam folder.

( 2015-01-09 01:16:49 +0300 )edit

I don't see such detailed information in the headers. The bottom line seems to be that my provider uses an unusual configuration and all I can do is whitelist the respective addresses. I just wanted to know if this is a major problem that affects a lot of others... which clearly it isn't. I'll therefore close this question. :)

( 2015-01-11 16:39:29 +0300 )edit

Sort by » oldest newest most voted

I'll post this as an answer although this is just a case study of an example message. I'm basing it on the idea aegis already mentioned, by looking at the raw headers of the email.

I've had the delivery confirmation (from Jolla shop, sender noreply@jolla.com) be marked as spam by iki.fi mail server, mostly due to three reasons:

1. Having a single graylist entry for one of the links in the mail (posti.fi, itella.fi, jolla.com or jolla.zendesk.com),
2. the sending host (a0i212.smtpcorp.com in this particular message, I think) not having a reverse DNS entry, and
3. not having plaintext part in the message (only MIME encoded HTML).

The 3rd one should be easy to fix by also having a plaintext version of the message, and if the greylisting is for jolla.com that should also be possible for the people of Jolla to sort out. Having a more reputable (?) SMTP service is also not so difficult to come up with. It was a close call, anyway, in this case, so sorting out any of those would have make it pass ok (even just formatting the message as a complete valid HTML would've done that).

Also in this case the filtering normally works fine, only true spam (or malicious email) is flagged.

X-Spam-Status: Yes, score=5.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
MIME_QP_LONG_LINE,RDNS_NONE,SPF_SOFTFAIL,URIBL_GREY autolearn=disabled
version=3.4.0
X-Spam-Report:
*  1.1 URIBL_GREY Contains an URL listed in the URIBL greylist
*      [URIs: mailchimp.com]
*  1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
*  0.0 HTML_MESSAGE BODY: HTML included in message
*  1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
*  0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
*  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
*      valid
*  0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
*  1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Spam-Level: *****
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on seuraava.iki.fi


Edit: Also updates from TCS seem to now be flagged by my provider, so it might be that they've changed their filtering lately (then again, I'm pretty new user so I don't have much perspective in this). In addition to the above scores, there're these ones adding up to the spam score:

*  2.4 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org
*      [listed in jolla.com.rhsbl.ahbl.org. IN]
[A]
*  1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822


Again things that could be fixed by sticking to standards / good practices and clearing up entries in DNSBLs.

more