Op de strafbank (zelf veroorzaakt)

Dit is nu al de tweede keer dat ik op de strafbank zit bij Soverin/Freedom.

Ik waagde een e-mail te zenden aan mijn eigen domein op mijn Freedom IP, terwijl mijn eigen server geen e-mails aanpakte.

Je krijgt dan de melding, vijf keer, in jouw Freedom mailbox dat de e-mail niet kon worden afgeleverd en dat later het nog eens geprobeert wordt.

In de tussentijd mijn e-mail server weer goed gezet maar de mail komt niet binnen.
Een email gezonden naar mijn tweede domein op hetzelfde IP, en die zijn dan ergens bij Freedom/Soverin maar die gaan ergens ter ruste.

Of ik die latere e-mails ooit nog zie is de vraag en dat weet ik waarschijnlijk past over vijf dagen, dan mag ik weer van de strafbank af mag.

Dus even een test e-mail zenden is bij Freedom er niet bij want dat doen zij niet aan mee.

domein A en B hebben dus een MX record dat wijst naar jouw Freedom IP

Hoe verstuur je email naar jezelf dat dan door soverin wordt afgehandeld?

Met mijn Freedom e-mail account. Dat is dan de mailserver van Freedom/Soverin die mail aflevert bij de mailserver die hier heb draaien.

Als ik het log kijk dan zie ik geen enkele pogingen om een e-mail aan te bieden. Vandaar ik ook schrijf ‘strafbank’.

Ik krijg overigens wel e-mails binnen van anderen.

Gewoon hardop denkend: logt je mailserver ook afgebroken delivery attempts? Dus bijvoorbeeld als remote probeert om TLS te gebruiken en dat faalt omdat je versie X.Y niet hebt ofzo. Welke mailserver draai je?

Als je mailserver Linux based is dan kun je een regel opnemen die logs bij ontvangst van een mail start pakket.

iptables -I INPUT -p tcp -m multiport --dports 25,465,587 --syn -j LOG --log-prefix "RING " --log-level 6 --log-ip-options
iptables -I INPUT -p tcp -m multiport --dports 25,465,587 --syn -j LOG --log-prefix "RING " --log-level 6 --log-ip-options

(waarom de regel twee keer: the postman always rings twice… (1 regel is voldoende)
De kernel log regels zijn dan in /var/log terug te vinden en te tellen. (is via dmesg live te volgen).

Het log draait 24x7 en de mailserver is Postfix. Bij Xs4all kon ik perfect testen en als het niet goed ging dan kwam de eerste e-mail later. Later gezonden e-mails kwamen direct binnen als de mailserver weer actief was.

Bij Freedom Soverin gaat er een soort blokkade op van wij konden geen e-mail afleveren en gaan dat de komende tijd ook niet meer proberen. Pfffff, verspilde moeite van onze kant.

Dat is inderdaad nogal non-standaard. Kun je dat hele soverin niet met een grote boog omzeilen? Persoonlijk doe ik dat.

Dan zou ik Freedom moeten opzeggen en teruggaan naar Xs4all, dat zie ik niet zitten.

Ik weet niet het duidelijk is. Freedom/Soverin is de verzendende partij en de e-mail is opgesteld in de webmail omgeving van Freedom en het verzendende e-mail adres eindigd op freedom.nl.

Ik zie zo geen mogelijk om die op een andere manier te laten verzenden.

Ik kan verder vanuit mijn eigen mailserver nog prima e-mails aan mijn freedom.nl mail zenden.

Het zuiver, dat Soverin het afleveren van e-mail weigert te doen zodra er één mail niet kon worden afgeleverd.

Het staat ook min of meer in de tekst in van de mail die ik terugkrijg van hun. Daar staat dat ik de e-mail opnieuw hoef te zenden. Ze nemen dat wel erg letterlijk en dan meteen voor alle e-mails ook gaan die naareen ander domein op hetzelfde IP adres.

De melding:

This is the mail system at host outbound.soverin.net.

####################################################################

THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE.

####################################################################

Your message could not be delivered for more than 4 hour(s).
It will be retried until it is 5 day(s) old.

Dit lijkt me typisch een geval voor de helpdesk van Freedom.

Dat zou de volgende stap zijn maar gelukkig kreeg ik een ingeving en die bleek niet helemaal juist te zijn maar genoeg om het werkelijke probleem te vinden.

Ik blok in firewall van de router via adreslijsten IP’s die scannen en ook vanuit het Hetzner, waar Soverin ook haar serves heeft staan, komen scans en Hetzner staat dus veelvuldig op de lijst.

Nu was het zelf afleveren van e-mails geen probleem en 99% van de inkomende ook niet. Ik ging ervan uit dat de verzendende server poort 25 gebruikte maar dat is een misvatting aan mijn kant.

Hierdoor werkte mijn ‘do not block’ lijst niet omdat het bron adres een random poort heeft en niet poort 25 waar ik vanuit ging.
Hierdoor werd de inkomende verbinding geweigerd in de firewall en die bereikte dus nooit de server en daarom was er ook geen mail log van.

Dus nu gebruik ik een speciale ‘do no block’ lijst, maar dan voor binnenkomende verbindingen voor services die ik hier heb draaien. Het is een korte lijst waar dus Soverin in staat en Microsoft om hun MTA-STS rapportages te geven.

Ik heb mijn nu zelf op de strafbank gezet! :wink:

2 likes

Die do not block lijst maakt gebruik van FQDN’s en rDNS? Anders moet je 'm om de zoveel tijd updaten.

Postfix kijkt naar de rDNS en mijn korte ‘do not block’ lijst in de router bevatten FQDN’s.

De ontvangende zijde bij Soverin heb ik net van vast naar FQDN gezet. En daarna naar Freedom omgezet voor het geval Freedom zelf de mail gaat afhandelen. Dan vervalt de CNAME die nu gebruikt wordt. Deze staan op de lange ‘do not block’ lijst omdat uitgaande verbindingen betreft.

1 like

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.