Valse spam melding door spamassassin

[Briolet]

Ik kreeg vandaag diverse mailtjes van een bepaalde firma die allen als spam gemarkeerd zijn door spamassassin

If you believe that this message has been incorrectly marked as spam, please
forward this email to postmaster.

Date: 20150731
pts rule name              description
---- ---------------------- --------------------------------------------------
2.4 DNS_FROM_AHBL_RHSBL    RBL: Envelope sender listed in dnsbl.ahbl.org
                           [listed in labeldiscounter.com.rhsbl.ahbl.org.   IN]
                           [A]
0.0 SPF_HELO_NEUTRAL       SPF: HELO does not match SPF record (neutral)
0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
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.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                           See
                           http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                            for more information.
                           [URIs: labeldiscounter.com]
0.6 HTML_MIME_NO_HTML_TAG  HTML-only message, but there is no HTML tag
0.4 RDNS_DYNAMIC           Delivered to internal network by host with
                           dynamic-looking rDNS
0.0 T_REMOTE_IMAGE         Message contains an external image

De hoogste spamscore kwam door de reactie op de bloklist: "dnsbl.ahbl.org" Echter, als ik op hun site "http://ahbl.org" kijk, dan zie ik dat die blocklist per 1 Januari 2015 opgeheven is en ze met een wildcard alle aanvragen als spam zullen terugmelden.
Ik heb elders gecheckt en hun IP komt inderdaad op geen andere spamlist voor.

Als ik op het label DNS_FROM_AHBL_RHSBL google, zie ik dat er meer mensen in Januari last van hadden.  De spamassassin check is onderdeel van de MailServer installatie. Het vreemde is waarom ik er nu last van heb en niet al veel langer. En waarom alleen deze afzender?

Herkennen anderen dit? Zo ja, reden voor een bugmelding?

[Erwin1]

Ik heb geen ervaring met deze firma, maar het gebeurt mij wel vaker dat berichten plots worden gezien als spam; en worden geplaatst in de ongewenste bus.
Ik check regelmatig deze postbus en mocht het een firma zijn die ik vertrouw voeg ik hem op de mailserver toe als vertrouwt (maar dat kost wel wat werk )

[Briolet]

Het probleem is niet zozeer de firma, maar dat de geraadpleegde DNS_FROM_AHBL_RHSBL filter niet meer ondersteund wordt en dus altijd een hit terugmeldt.

Lijkt me een bug in MailServer dat zij het spamassassin pakket niet regelmatig updaten.  De tip die ik overal lees is om de config file "local.cf " van spamassassin aan te passen door de volgende regel toe te voegen:

score DNS_FROM_AHBL_RHSBL 0

En hierna de spam deamon te stoppen en te starten. Voor Mailserver is dat niet voldoende omdat de config file elke keer weer overschreven wordt als je de spamcheck opnieuw aan zet. Beter is het om de template file aan te passen. Dan in Mailserver de spamcheck even uit en dan weer aan te zetten. Dat restart de deamon ook en voegt de aanpassing aan de config file toe.

Template staat in:
/var/packages/MailServer/target/etc/template/spamassassin.template

de config file zelf in:
/volume1/@appstore/MailServer/etc/spamassassin/local.cf

En nu maar hopen dat het bij een volgend mailtje van deze firma weg blijft.

[Erwin1]

Is het niet beter om dit neer te leggen bij Synology, ze moeten wel een goed product afleveren..

[Briolet]

Maar ik wil eerst weten waar de fout ligt, vandaar de melding hier met de vraag naar ervaringen van anderen.

Ik heb wel de indruk dat de versie van spamassassin op de nas 3.4.0 is en de nieuwste versie is 3.4.1. Alleen wel ik niet of deze lijsten hardcoded op de nas staan, of periodiek van het internet gehaald worden. In dat laatste geval kan synology er niets aan doen.

In elk geval is er geen lijst waar je simpel de DNS_FROM_AHBL_RHSBL regel kunt wissen. De spammassassin pagina zelf geeft ook de methode van het toevoegen van een filter met score 0 aan de config file aan als de aangeraden methode  i.p.v. het aanpassen van een lijst.

Als puzzelaar blijf ik me afvragen is waarom deze mailtjes mis gingen door deze check de al een half jaar ongeldig is. Ik zie wel dat de mail ook een spamm score krijgt voor het SPF record. De verzender heeft het SPF record ook niet op orde omdat ze verzenden vanaf een IP dat niet in het record staat.

Uit de mailheader:

Received-Spf: neutral (labeldiscounter.com: Default neutral result due to no mechanism matches) receiver=GedeeldeData; identity=mailfrom; envelope-from="shop_production@labeldiscounter.com"; helo=labeldiscounter.com; client-ip=54.229.177.223

De reden dat hij niet blokt op het SPF record is omdat het record van de afzender ingesteld staat om foute IP adressen neutraal te behandelen. Misschien dat dit de trigger was voor spamassassin om deze mail zelf met aanvullende filters te testen. Wat dat betreft moet de mail afzender ook beter zijn huiswerk doen.

Je mail beveiligen met SPF is goed, maar als je dat niet goed doet, kan het juist tegen jezelf gebruikt worden.

[Briolet]

Ik zie net dat dit probleem ook al begin jan 2015 op het engelse synology forum gemeld is. Dat was ook een logisch moment omdat die lijst toen ongeldig werd.

Ook op het Duitse synology forum wordt deze bug gemeld. Dat was echter recenter in mei van dit jaar. Daar wordt ook gemeld dat deze bug doorgegeven is.

De Duitse site geeft ook de beste fix. Je moet in de file:
/volume1/@appstore/MailServer/share/spamassassin/20_dnsbl_tests.cf

het stuk

Code: [Selecteer]

# another domain-based
blacklist header DNS_FROM_AHBL_RHSBL     
eval:check_rbl_envfrom('ahbl', 'rhsbl.ahbl.org.')
describe DNS_FROM_AHBL_RHSBL    Envelope sender listed in dnsbl.ahbl.org
tflags DNS_FROM_AHBL_RHSBL      net
reuse  DNS_FROM_AHBL_RHSBL
Wissen of in comment omzetten. In principe moet je deze file niet aanpassen omdat hij bij elke update weer vervangen wordt, maar in dit geval verwacht ik dat het bij een spamassassin update ook verwijderd is.

Edit: Ik heb net een bugreport hierover naar Synology gestuurd.

[DrBean]

Ik liep er gisteren ook tegenaan, en kwam dit topic tegen. Heb daarnet ook maar een ticket ingeschoten (en toen zag ik je edit, Briolet)

[Briolet]

DrBean: des te meer meldingen des te beter. Meer kans dat ze sneller updaten.

Ik vroeg me steeds af waarom ik dit nooit eerder zag, omdat de test al sinds 1 Januari moet falen. Een betere blik in de header gaf de reden:

X-Mailscanner-Spamcheck: spam, SpamAssassin (not cached, score=5.207, required 5, DNS_FROM_AHBL_RHSBL 2.44, HTML_MESSAGE 0.00, HTML_MIME_NO_HTML_TAG 0.64, MIME_HTML_ONLY 1.10, MIME_QP_LONG_LINE 0.00, RDNS_DYNAMIC 0.36, SPF_HELO_NEUTRAL 0.00, SPF_NEUTRAL 0.65, T_REMOTE_IMAGE 0.01, URIBL_BLOCKED 0.00)

Dit is dezelfde mail als bij mijn eerste post. In de header wordt de score echter op 2 decimalen weergegeven. In de mail zelf zijn de getallen op 1 decimaal afgerond. Ik zie nu pas de opgetelde score van 5,207 met een drempel van 5,00. 5,00 is de default instelling die je zelf kunt aanpassen.

Bij de meeste mailtjes is dus de foutieve DNS_FROM_AHBL_RHSBL test niet voldoende om hem als spam aan te merken. Bij dit mailtje was echter veel meer mis. Hij krijgt punten voor een te vrijblijvend SPF record en punten voor misleidende links in de mail. : De link heet "helpddesk Labeldiscounter.com" maar je wordt gestuurd naar "www.labeldiscounter.com".

Als je niet in de code wilt editten kun je de spamdrempel ook met 2,44 ophogen totdat deze bug gefixed wordt.

[DrBean]

Tja, je zit meteen aan de helft met die onnodige punten, en dan gaat het vrij snel. Hier was het een entry op een greylist, een entry op spamcop (die niet blijkt te bestaan...rara), en nog wat klein grut.

Ik heb het genoemde bestand al gewijzigd (ik zag jouw bericht pas nadat ik het hier gezien had: http://svn.apache.org/viewvc/spamassassin/trunk/rules/20_dnsbl_tests.cf?r1=1643132&r2=1650258&pathrev=1650258&diff_format=h), maar de score ophogen is een prima optie.

Interessant dat Synology de rules niet meer heeft geupdate sinds ten minste 26 maart vorig jaar: toen is de rule al uitgecomment in de Spamassassin source...

[Briolet]

…dat Synology de rules niet meer heeft geupdate sinds ten minste 26 maart vorig jaar:…

Diegene die de commit deed was ook van slag want hij schrijf als datum twee dagen later op. 

Maar ik kan me voorstellen dat Synology alleen de release versies wil installeren. Ik heb ook jaren gewerkt aan een project dat via SVN werkte. De dagelijkse tussenversies kunnen vol met bugs zitten dus ik kan me voorstellen dat Synology niet elke update wil implementeren.

Ik schrok echter van de TAGS. Normaal tag je toch alleen releseversies? Van versie 3.4.0 hebben ze honderden versies getagd. En versie 3.4.1 is in 7 december 2014 reeds als release getagd, maar op de Apage pagina wordt versie 3.4.1 pas op 3 april 2015 als nieuwe release gepresenteerd.

Ik had wel verwacht dat deze update in Mailserver versies na deze datum aanwezig zou zijn. En Mailserver is na deze datum al eens ge-update.

[DrBean]

Diegene die de commit deed was ook van slag want hij schrijf als datum twee dagen later op. 

Heh, niet eens gezien

[..] ik kan me voorstellen dat Synology niet elke update wil implementeren.

Tja, je zegt het zelf al: Er komen regelmatig updates uit voor MailServer. Ik verwacht eigenlijk dat ze onderdelen van dat package goed in de gaten houden, mede omdat dit package in bedrijfsomgevingen wordt ingezet, en maatregelen tegen spam/phishing/malware erg belangrijk zijn. Als ik er niet op kan vertrouwen dat het in een package zit, dan installeer ik Postfix en bijgehorend spul misschien net zo lief handmatig :/

Ik schrok echter van de TAGS. Normaal tag je toch alleen releseversies?Va n versie 3.4.0 hebben ze honderden versies getagd. 

Misschien snap ik niet goed wat je bedoelt, maar er is toch maar 1 tag voor release van 3.4.0: spamassassin_release_3_4_0? Al die andere zijn RC's of nightlies (met een achtervoegsel in de vorm van datum en buildnumber). Die zijn misschien getagd voor het automatiseren van builds via een buildbot, of het makkelijker maken van downloaden van nightlies via `svn checkout`.

En versie 3.4.1 is in 7 december 2014 reeds als release getagd, maar op de Apage pagina wordt versie 3.4.1 pas op 3 april 2015 als nieuwe release gepresenteerd.

Die begrijp ik sowieso niet, want er is dan weer geen tag voor de officiele 3.4.1 release...alleen voor RC1, en een lading nightlies...of kijk ik er overheen?

[Briolet]

Blijkbaar zijn er verschillende policies. Ik ben gewend dat alleen de versies en updates voor een publieke release getagd worden. Dat houdt dat lijstje met oude releases ook wat overzichtelijker.
Nighties zijn zo vergankelijk dat om de paar dagen een versie vastzetten ook een beetje overkill lijkt.

Ik miste echter de echte 3.4.1 release versie en zag alleen versies ouder dan 6 maand. Blijkbaar zat er in de tag-link van mij hierboven nog een selectie om alleen tot een bepaalde revisie nummer te laten zien. Nu ik de link goed heb, zie ik alles en maken de versies het ook meer zin. Ik zie nu ook release versie 3.4.1 er tussen staan.

PS: waar staat RC voor in het versie nummer? Een officiële beta versie?

[DrBean]

RC=Release Candidate. Van minst stabiel naar stabiel geordend kun je je iets voorstellen als: nightly>alfa>beta>rc>final. Afhankelijk van hoe life cycle management/release management is vormgegeven zijn daar natuurlijk veel variaties in te bedenken: andere namen, meer- of juist minder 'stappen' etc.
 
Die tags voor de nightlies zijn praktisch omdat je als gebruiker of tester eenvoudiger een checkout kan doen van software-datum-buildnummer, ipv het opzoeken van een revision of hash. Het zetten van die nightly tags is overigens geautomatiseerd, al dan niet icm geautomatiseerde tests...als het handmatig moest, zou het nooit worden gedaan

[Briolet]

Ik ben nog eens enkele oude mailtjes doorgelopen en het klopt dat er vanaf januari vaak de melding "X-Mailscanner-Spamscore: ss" in de mailheader staat. Als de spamscore onder de drempelwaarde blijft geeft hij niet de uitgebreide score of zelfs maar het kale getal, maar hij geeft de op een heel getal afgeronde score aan met het aantal s-jes.
Ik had die s-jes vaker gezien maar wist nooit precies wat dat betekende. Nu ik in al die handleidingen gedoken heb, heb ik in elk geval weer het nodige geleerd.

Als de basis score nu nu met 2.4 verhoogd is zijn dat dus al standaard twee s-jes.

Anderzijds betekent het feit dat dit mijn eerste treffer in een half jaar was, dat ik de spam-drempel gerust met 2.4 punt kan verlagen zonder er echt last van te krijgen.

[Briolet]

Op het engelse forum kreeg ik de beste tip om deze bug te verhelpen.

Spamassassin heeft een ingebouwde updatefunctie om steeds de meest actuele filters te downloaden. Lees hier: https://wiki.apache.org/spamassassin/RuleUpdates

Alleen heeft Synology het daar genoemde commando "sa-update" niet ge-implementeerd. Je kunt de update functie echter wel activeren door in de terminal in te geven:

Code: [Selecteer]

/var/packages/MailServer/target/bin/sa-update
Dit plaatst dan een folder met de laatste versie van alle filters in

Code: [Selecteer]

"/var/packages/MailServer/target/var/spamassassin/3.004000/updates_spamassassin_org/"
Elke keer als er een nieuwe release van regels is zal hij er een nieuwe folder bijplaatsen met hoger versienummer. Spamassassin gebruikt steeds de regels uit de nieuwste folder. De oude moet je dan handmatig een keer wissen. De originele filters blijven op hun plaats en worden blijkbaar niet meer gebruikt. Ik heb dat geverifieerd door mijn eerdere aanpassingen ongedaan te maken en dan een mailtje binnen te halen.

Dus eigenlijk moet je de bovenstaande code in de taakplanner invoeren zodat periodiek gekeken wordt of er nieuwe regels beschikbaar zijn. Dit had natuurlijk een vast onderdeel van MailServer moeten zijn.



En dan 1x per week of 1x per maand. Zoals de auteurs zelf ook aangeven worden die regels zo vaak geupdate dat je niet steeds kunt wachten totdat er een nieuwe spamassassin release uitkomt. Je moet ook tussendoor updaten.