Meer mail belandt in spam-map

Storingspagina’s hebben ook een vervelende eigenschap dat die het imago - kunnen - gaan bepalen van een provider.
Freedom moet maar kan ws geen echte druk zetten bij Soverin om dit sneller op te lossen. Het nadeel van uitbesteden is dan dat Freedom het hier maar moet afwachten. Iets dat geldt voor meer issues.

Ook vermoed ik dat Freedom niet echt ‘weet’ of, hoe en waar zij het precies zoeken moet.
Voor de één werkt iets goed omdat die er “geen last” van heeft en voor de ander, is het een storingsissue omdat een kennelijke policy verandering (ineens) problemen veroorzaakt.

Daarom ook mijn pleidooi dat spamcomponenten en de formule daarvan, instelbaar moet zijn door gebruikers zelf. Technisch niet heel moeilijk maar erg complex om te realiseren.
De partij die de mail verwerkt, dat ook moet willen implementeren. Probleem hier is weer dat het gros van mailgebruikers daar geen belang in- of behoefte aan heeft.

Dan hebben ze de verkeerde (contractueel) keus gemaakt want dan Feedom daardoor niet de benodigde service voor zijn klanten leveren. Freedom kan zich niet verschuilen naar klanten toe met verwijzen nara onderaannemers. Als klant heb ik dara helemaal niets mee te maken. Ik ben klant bij Freedom, dus zij regelen het maar, daar betaal ik voor.

Dat is dan vooral een zienswijze (waar ik het mee eens ben) die ook anders gelezen kan worden. De keus is destijds door omstandigheden ‘gemaakt’ en wij als gebruikers hebben dat weer als onderdeel van “onze” overeenkomst feitelijk geaccepteerd.

Zelf vind ik het ook erg jammer dat Freedom uiteindelijk een doorgifte partij lijkt te zijn en niet zoals ik (ooit) hoopte een zelfstandig autonoom opererend, technisch innovatief gestoelde organisatie.
Dat is geen kritiek op personen of hun inzet maar simpelweg een constatering dat Freedom niet zelf de klantfunctionaliteit ontwikkelt en dat vooral over laat aan welwillende derden.
Bijkomende uitdaging daarvan is dat Freedom zich in bochten moet wurmen om die tussenpersonen en instanties te “vriend” te houden.
Iets waar een ooit eigenwijs xs4all, doorgaans lak aan had (en ook kon hebben) omdat de techniek in eigen beheer en gebruikers invloed hadden hoe die werd toegepast.

Consequentie van afhankelijkheid is dat Freedom hooguit kan pushen om iets goedbedoeld (in) te regelen en voorzichtig moet omspringen met hoe haar leveranciers aanspreekt die Freedom (en ons dus) anders zullen ghosten.
Allerlei acties, mogelijke functies zoals telnet; ssh, ftp, cloud, websites, tv, firewall, monitoring, snelheden, inriching mail en wat dies meer zoals eigen netwerkdiensten etc.etc.; zijn allemaal afhankelijk van anderen.

Dat iemand als klant zegt, daar niets mee te maken te hebben is dan de ogen sluiten voor die werkelijkheid. Het is erg lastig om te beschrijven wat nu precies de services zijn die Freedom ons zou moeten leveren omdat die buiten een vage omschrijving zaken niet toetsbaar noch inhoudelijk gedefinieerd zijn.
Kortom, als zijnde “klant” is er weinig waarop die zich kan beroepen.

Probleem is dat het niet schaalbaar is… ipv. een mail die naar verschillende mensen gaat een maal te beoordelen moet die voor elk van de ontvangers apart beoordeeld worden.
En dat wordt een hoop werk, ook voor aspecten die feitelijk alleen goed kunnen worden beoordeeld op connect time.

Heel veel spam.phishing etc. is effectief te stoppen door vrij strakke controle op het strict volgen van het SMTP protocol…
en niet uit te gaan van accepteer veel en wees zel zo strak mogelijk conform de specs.
Naast allerlei extras zoals SPF/DKIM/DMARC. Het heeft weinig zin om een mail eerst te accepteren en controleren als SPF records aangeven dat ontvangst vanaf het zendende adres zinloos is omdat die dat niet mag verzenden.
Als dat in orde is dan heeft een evaluatie op kenmerken van de inhoud pas zin.

BTW, rspamd is een soort amavis ( spamassassin hulpmiddel) geschikt voor verwerken op grotere schaal.

Dat individueel “beoordelen”, gebeurd nu toch ook/al ?
Of je bedoelt met moment waar nu alle mail nu aan de voorkant bij binnenkomst als één bulkstroom wordt gemarkeerd met concept headers en pas dan wordt doorgezet naar een gebruiker.

Interessant zou zijn te weten wat precies de procesflow van mail is. Ook om inzichtelijk te maken waar dat - zoals nu - mis zou kunnen gaan.

In het vervolgproces zou mbv zeg mailregels, een uit/insluiting kunnen plaatsvinden op grond van gevinkte header-velden. Het (bulk) inname proces zet dan initiéle spamwaarden die in mijn suggestie, bij aflevering alsnog wordt herbeoordeelt op grond van individuele if-then-else gebruiksinstellingen.
De eventueel bijgestelde sparwaarde bepaalt dan op grond waarvan iets in een spammap komt.

2 likes

Van de ruim 80000 mail / maand die er aangeboden dreigt te worden kan ik op het eerste gezicht (ROKSO, e.d. blacklists) 80% al weigeren op grond van IP adres … (bekende spammers)… Daarna SPF/DKIM check haalt er nog eens 10% af.
uiteindelijk blijven er een 2500-3000 / maand over die lezenswaardig zijn na beoordeling door rspamd / spamassassin.
Ik denk niet dat ik bijzonder veel extra spammers aandacht krijg. Dus dit soort getallen geldt voor elke mail ontvanger.

Dus ik zou m’n infra structuur serieus moeten uitbreiden naarmate de beslissing later wordt genomen om wel/niet te filteren.
(nu wordt ~ 10% van de aangeboden zooi door rspamd/spamassasin getrokken).
rspamd kan meer dan spamassassin…, het heeft meer gereedschap in huis dan alleen bayesian en keyword checks. rspamd kan in de actieve keten zitten en kan dan ook greylisting, DCC clearinghouse etc. raadplegen.

Ik gebruik postfix om mijn mail te ontvangen. Een simpele truc om spam tegen te houden is om tijdens het binnenhalen van de mail 15 seconden te wachten. De meeste spammers haken na 3 seconden al af…

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        sleep 15,
        check_recipient_access  pcre:/postfix/tables/recipient_checks,
        check_helo_access   ...... enz....
1 like

Erg leuk en heel goed bedacht @jcmraats
Maar waar doe je zoiets dan invullen, of aanpassen?

Ben niet zo thuis in dat soort dingen, daarom vraag ik het maar :slight_smile:

Je hebt groot gelijk om het te vragen. Ik draai mijn eigen mailserver thuis. Dat betekent dat ik beslis wat binnenkomt en wat niet. Ik reageerde op het voorgaande bericht die ook een eigen mailserver heeft draaien.

2 likes

Waarbij je de dingen ook zelf moet onderhouden, monitoren om te voldoen aan de eisen die verzendpartijen aanleggen om bij/op jouw mailserver hun mail af te - laten - leveren.
Last but not least, mag je ook “zelf” beslissen om aan al die eisen tegemoet te komen om mail te kunnen ontvangen en een server met waar daar verder voor nodig is (backup/recovery/firewall etc.etc) veilig actief te houden.

Voor het gros van gebruikers is een eigen server/oplossing nauwelijks een optie en die willen gewoon zelf volledige controle hebben over het gevoerde spam-beleid en de componenten daarin.

Dat is in derdaad de enige manier om het zelf ind e hand te hebben. Helaas is dat niet voor ‘de leek’ weggelegd met alle hoepels waar je tegenwoordig doorheen moet springen. (Maar voor een IT’er een leuke bingeroefening)

Overigens gaat de 15 sec wait hier fout, mijn mail gaat via een externe relay server, zowel inkomend als uitgaand en dan zie ik de tls connectie droppen. Leuk om eens uit te zoeken of 5 sec wel werkt, al denk ik dat de timeout de tls layer in de weg zit. Greylisting moet dan maar genoeg zijn. (helaas denken nog steeds veel mail beheerders dat mail per direct aangenomen moet worden en geven op)

Iverigens komt mail van mijn eigen domeinen bif steeds in de spam box bij freedom. De soverin server geeft nog steeds aan dat de DNS een timeout geeft terwijl de rest van de wereld geen problemen heeft.

Het probleem lijkt nu opgelost, althans bij mij gaat het goed.

Hetzelfde bij mij, 'het gaat ook weer goed.

Hier nog steeds bende. Soverin lijkt maar te weigeren de nieuwe DNS servers van m’n domeinen te raadplegen. Volgende ticket. (bij soverin melden mag ik niet van ze als Freedom klant)

Het probleem lijkt hier ook opgelost te zijn. Via de mail heb ik contact gehad met Freedom en die hebben header informatie gezien en daar is iets mee gedaan :slight_smile:

Mocht het fout gaan dan laat ik het zeker weer weten.

Hier is het probleem helaas nog niet opgelost, er kwam een nieuwsbrief van een keurige instantie in de spambox terecht. Voorheen kwam deze nieuwsbrief zonder problemen voorbij de spamfilters. De headers zijn naar de helpdesk gestuurd.

Hiervoor ben/was ik o.a. (ook) lid van Soverin, zodat ik dingen daar ook kan melden en niet via Freedom dat lijkt te filteren. Niet dat je bij Soverin veel verder komt maar het elimineert een vertalende bezigheidsschakel.

Grappig blijft de standaard script vraag van “screenshots”, net of dat een technisch gebrek daarop zichtbaar is. Irritant is wel hoe je aan iemand die het zelf niet helemaal snapt, moet bewijzen dat iets niet functioneert.
Maar goed, we spelen het spel inmiddels als vermakelijk tijdverdrijf - het houdt je systeemdenken alert - zoals de partij dat kennelijk wenselijk acht.

Ondertussen lost het echte probleem zichzelf op door sommige sleutelzaken zeker niet bij Freedom e/o Soverin te doen.
Soms krijg ik een verheugende vraag of een langlopend ticket nu wel gesloten kan worden (niet dus) omdat er geen melding vanuit mijn kant meer is geweest.

Hoe scoort je mailserver bij internet.nl? Die van mij scoort 100% en heeft geen problemen met het afleveren van de mail bij Freedom. Bij Freedom moet wel de reverse DNS goed staan.

Het probleem was hier na 4 mei 's middags over zoals ook gemeld werd bij Storingen, maar treedt sinds de nacht van 8 op 9 mei weer af en toe op. Keurige berichten met SPF, DKIM, DMARC pass die ik normaliter in mijn Inbox krijg komen nu weer in spam met tegenstrijdige X-Soverin-Spam headers:

X-Soverin-Spam-Status: No, score=5.30
X-Soverin-Spam-Level: *****
X-Soverin-Spam-Bar: +++++
X-Soverin-Spam-Result: default: False [5.30 / 15.00];
	HTML_SHORT_LINK_IMG_1(2.00)[];
	NEURAL_SPAM(1.33)[0.889];
	SUBJ_EXCESS_QP(1.32)[];
	URI_COUNT_ODD(1.00)[11];
	DMARC_POLICY_ALLOW(-0.50)[market.envato.com,none];
	FORGED_SENDER(0.30)[do-not-reply@market.envato.com,bounce-md_30000325.64596f61.v1-e10d03e853034265bcb46ce55e6bdc24@mandrillapp.com];
	FROM_NEQ_ENVFROM(0.25)[do-not-reply@market.envato.com,bounce-md_30000325.64596f61.v1-e10d03e853034265bcb46ce55e6bdc24@mandrillapp.com];
	R_DKIM_ALLOW(-0.20)[market.envato.com:s=mandrill,mandrillapp.com:s=mandrill];
	R_SPF_ALLOW(-0.20)[+ip4:198.2.128.0/24:c];
	MANY_INVISIBLE_PARTS(0.10)[2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related];
	MX_WHITE(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[198.2.128.2:from];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~,5:~,6:~,7:~,8:~];
	RCVD_IN_DNSWL_NONE(0.00)[198.2.128.2:from];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ASN(0.00)[asn:14782, ipnet:198.2.128.0/19, country:US];
	PREVIOUSLY_DELIVERED(0.00)[willem@homelan.nl];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[market.envato.com:+,mandrillapp.com:+];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[]