Infra soverin email

Hey allen,

heeft iemand wat docs of code dat laat zien hoe soverin/freedom hun E-mail heeft ingericht? Ik vind de oplossing user@delimiter.domain.tld best tof, omdat vaak e-mail input velden user+delimiter@domain.tld niet correct vinden. Nu wil ik dat zelf ook graag realizeren, maar ben beetje duister wat ze precies doen. Een catch all? dns entries toevoegen voor elke delimiter (lijkt me stug), dus ben beetje op zoek naar de truukjes die ze gebruiken om dit mogeljk te maken, zonder tot in den diepte de details uit hoeven te zoeken.

Wil je dit op je eigen mailserver inrichten of wil je dit voor je Freedom Mail inrichten?

tldr; generiek verhaaltje hoe userid-catch+all werkt.

Kern is dat een mail ‘ergens’ wordt afgeleverd op de server als aangeduid in/door het generieke (domein.tld) MX record als ingesteld in/door DNS.

Vervolgens gaat de software (luisterend op socket/poort) op die server simpelweg de mail op grond van mail-velden w.o. To-adress uit -en insplitsen. Vervolgens wordt die ‘mail’ met aanvullende filters en allerlei (evt. virus & authenticatie) checks in de aangeduide ‘map’ van een ontvangende user-mailbox (in de database) geplaatst.

Ik vermoed dat Freedom/Soverin, PostFix gebruikt als mailserver waaraan zij vervolgens het nodige (icm oa MySql voor ingestelde stuurdata) hebben gesleuteld om te bereiken wat ze aanbieden.

Op basis van DNS, mail ‘door/routeren’ kan ook en is dan vooral bedoeld om via MX records, een mail al op voorhand te redirecten naar de afhandelende server.
Indirect is dat ‘effect’ ook te bereiken met (eventueel intern) doorsturen naar een andere MailTransferAgent wat dan een extra transfer (door/ver)stuurstap vraagt.

Hoe precies het technisch kan -en wordt geregeld is dan een zoekplaatje van creativiteit. In de basis is het een (soort met naar ik vermoed RegEx gefilterde) catchall methode. Zeker met de (open)source in de hand zijn die ‘trucjes’ niet zo ‘moeilijk’, wel bewerkelijk - en daarom vaak het ‘bedrijfsgeheim’ - om het vanaf de grond te (ver)maken en vooral te kunnen beheren.
Dit beheren is misschien wel het belangrijkste. Trucjes die niet goed zijn te beheren (denk aan software upgrades/updates), zijn vooral een voortdurende zorglast.
Eén van de redenen dat providers vaak alleen aanbieden wat standaard in een software-oplossing zit. Het ‘trucje’ zou best kunnen maar ze doen het niet omdat het …vul-in… is.

Zover ik weet doen we voor IMAP Dovecot. En volgens mij er worden een heleboel mogelijkheden gebruikt die standaard daar al in het pakket zitten.

Dus hier heb je een heleboel informatie over Dovecot. :smiley:
https://doc.dovecot.org/

Hoe kom ik daarbij? Nou…

% nc imap.freedom.nl 143
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS LOGINDISABLED] Dovecot ready.

Je hebt met verschillende zaken te maken:

  • hoe zorg ik dat de mail op de server komt. dat doe je met MX records in DNS. een wildcard record in DNS dat kan, maar meestal ga je daar uiteindelijk spijt van krijgen. ik weet niet of je met “delimiter” eigenlijk “subdomein” bedoelt maar het ontvangen van mail op willekeurige, niet van te voren geconfigureerde subdomeinen dat vereist dus zo’n wildcard MX
  • hoe zorg je dat de mail die bij de server komt aangepakt wordt en niet geweigerd. je kunt alle mail aanpakken, maar wederom daar ga je uiteindelijk spijt van krijgen. beter is om in ieder geval een lijst van geldige adressen aan te houden (in een database of een map file in je server) die meteen al bij aanbieden kan zien of een adres geldig is of niet, en ongeldige adressen kan weigeren. maar dan moet je dus wel zo’n lijst vantevoren opgeven.
  • de binnen komende mail wil je meestal checken op allerlei zaken zoals spam, virussen, etc. daar gebruik je iets als SpamAssassin of Amavis voor.
  • tenslotte moet je de aangepakte mail in mailboxen stoppen en wellicht in (sub)mappen afhankelijk van criteria zoals het daadwerkelijk gebruikte mailadres. daar komt dovecot in beeld, die de mailboxen beheert, en er met dovecot-lda (aangeroepen vanuit je mailserver zoals postfix) mail in plaatst, eventueel na raadplegen van filter regels (sieve).
  • deze dovecot mailboxen en mappen kun je dan weer lezen met een mailprogramma wat IMAP ondersteunt (zoals Thunderbird), of met bijvoorbeeld een webmail zoals Roundcube.

Hey Frank,

ik heb mn eigen miail al decenia, en gebruik recipient delimiters. Dit truukje toepassen op domein niveau was nieuw voor me, maar vind het wel erg tof, omdat je dan toch ‘per spammer een uniek mail address’ kan inrichten, zonder de recipient delimeter problemen.

Alleen googlen op deze techniek is wat lastiger, dus vandaar mijn nieuwgierigheid zodat ik dit zelf met mn postfix kan inrichten.

pe1chl, bastiaan; thanks :slight_smile: dat jullie voor imap dovecot gebruiken is niet heel gek :slight_smile: maar dat is met name voor het lezen. Recipient Delimiters (de + in je mail) is een ‘veel voorkomende’ SMTP server config, ik (net als freedom) gebruiken tot zover ik weet postfix, waar dit ook prima kan.

Om postfix te laten luisteren/accpeteren van user@delimiter.domain.tld is volgens mij niet zo heel lastig, want uiteindelijk doet postfix (in mijn geval) iets als user@…domain.tld → mailbox. Gezien je met wat slimme sql queries dat zelf inregeld, kan je dus heel goed het postfix gedeelte doen. Handig was het geweest om die SQL regels van freedom/soverin te zien :slight_smile: scheelt weer wat uitzoek werk. Mijn sql regels zijn al 15+ jaar het zelfde, dus vrij stabiel, een aanpassing hierin zal dan ook niet super ingewikkeld zijn.

Dan blijft de DNS vraag eigenlijk open. Als ik een mx entry op het top level heb (dus mx:domain.tld; heb je hier geen catch-all mx record. Maar mss is dit de missing link waar ik naar op zoek ben. Catch all domain ken ik; maar catch-all mx record niet …

Goed verhaal, hier een verbandhoudende plaat (van XenLens):


Afhankelijk van platform, wens, software en commercie; zjn er tal van andere oplossingen. Soverin zelf zit iig op de opensource lijn. Zover ik weet gebruikt Soverin Caddy ipv Nginx.

Hoe en waar je alles moet doen om Soverin te imiteren hang ook samen met hoe Soverin haar hele management en orderstraat (geautomatiseerd) heeft ingericht.
Management is en kan voor thuisgebruik niet echt nodig zijn. Hier ook opmerken dat je bij Soverin gebruik kunt maken van PGP encryptie, zowel specifiek voor Webmail (dwz Roundcube) als offline voor zeg Thunderbird.

Dat zeg ik, dan moet je een wildcard MX record maken. Dus in je zone zet je:

“* MX 10 server.domain.tld.”

Maar ik zeg: je gaat er uiteindelijk spijt van krijgen. Beter kun je die subdomeinen van te voren vastleggen en een paar expliciete MX records maken, dus:

“subdomein1 MX 10 server.domain.tld.”
“subdomein2 MX 10 server.domain.tld.”

enz. Dat werkt prima als je bijv een apart domein per gezinslid wilt en daarbinnen dan usernamen per toepassing ofzo. Komt er een bij dan moet je je DNS even aanpassen.

Ga je met * werken dan ga je (net als met CNAME) tegen een paar hele rare beperkingen in DNS aanlopen. Beter niet aan beginnen.

1 like

tldr: Zijstapje…

Ik heb in een grijs verleden wel exits/stubs geprogrammeerd op/voor “DNS” waarna dat dan (met en voor anderen) geen probleem meer hoeft te zijn.
Gebruikers moesten mail sturen in formaat “to@from.domain.tld” en als iemand een onbekende to&from hanteerde, kreeg de sturende SMTP geliijk al bij de voordeur een 550 (unknown host) voor de kiezen. Scheelde een berg resources.

Ik geef onmideelijk toe dat verbouwen, doorgaans niet de anbevolen weg is.
Los daarvan is het software en als het op/voor je eigen spul is (..domain.tld), who cares. Een universele catch-all op ‘DNS’ kan soms best handig zijn zodat je daar niet meer hoeft te zijn om via DNS active subdomein mail af te handelen.

Nee maar het kan nooit lang duren voordat je dit uitbreidt naar een wildcard A record of je denkt “hee ik heb twee domeinen example.com en example.org weet je dat dan zet ik in example.org gewoon * CNAME example.com” en dat soort dingen gaat dus afschuwelijk fout.
Als je de definities in DNS ziet van * en CNAME dan zie je allerlei dingen die anders werken dan je zou hopen.

pe1chl, ik snap waarom je dit zegt, aan de andere kant, soverin/freedom doen dit dus overduidelijk toch ook dan? is er een dig command waar we dit bij uit kunnen lezen wat ze doen?

Ik mag toch aannemen dat als je zelf een mail domein bij Freedom/Soverin hebt ondergebracht, je zelf in je DNS editor kunt zien wat ze daarvoor geconfigureerd hebben?

idd. Soverin heeft alleen maar een koppeling tussen Database en DNS nodig.
Alle data is al aangeleverd, er is geen wildcard nodig.

Ik gebruik juist niet soverin/freedom DNS/mail, maar wil dit repliceren, vandaar dus dit topic. wildlcard mx dns entry dus.

Overigens, mooi plaatje, dit is ook mijn setup; enkel gebruik ik apache, postgres en (nog) courier-imap en staat pop3 uit.

Freedom gebruikt idd catch-all “*” op MX waarmee alle mail voor dat ‘domain.tld’ door dezelfde server wordt ingelezen.

Lijkt mij als replicatie vanaf dat punt dan dus een kwestie van waarschijnlijk PostFix zo af & inrichten dat die op basis van RegEx/replace selectie dan inkomende (mailbox=.*@mailnaam.domain.tld en/of mailnaam"\+.+@domain.tld , de ‘catchall’ inkomende mail dan uitsplitst/doorzet naar de gewenste (alias) mailbox als aangeduidt door mailnaam.

Hoe, - ik weet: je hamvraag voor het precieze miljoen - is dan (je) vooral verdiepen PostFix-setup/filtering zodat die een mail inspecteert en dan in de juist mailbox-database plaatst. Welke onderliggende zaken je gebruikt (database/http) lijkt mij niet echt van invloed.

Dat zeg ik, dan moet je een wildcard MX record maken. Dus in je zone zet je:

“* MX 10 server.domain.tld.”

Maar ik zeg: je gaat er uiteindelijk spijt van krijgen. Beter kun je die subdomeinen van te voren vastleggen en een paar expliciete MX records maken

Maar dat kan niet als je het wilt gebruiken voor een dynamische functie als ‘aap+noot@mies.com’ waarbij ‘noot’ alles mag zijn. Zo werkt hetgeen @schinagl wil bereiken. Als je wil voorkomen dat je hoofddomein verontreinigd raakt met een wildcard-mx, kan je mail via een subdomain laten lopen en daar een catchall op zetten.

Ehh nee daar is dat niet voor nodig! Een MX record werkt op basis van domein, en in dat voorbeeld heb je alleen een MX voor mies.com nodig en geen wildcard MX. De usernaam binnen dat domein is aap+noot en de afwikkeling daarvan zit in je mailserver/local delivery agent. Die herkent dat (als het goed is) en levert het af in de mailbox aap, het gedeelte +noot negerend dus. Dat kun je wel weer gebruiken in een filter.

Een wildcard MX heb je pas nodig als je ook mail aan aap@noot.mies.com wilt kunnen aanpakken waarbij noot een willekeurige waarde is waar je niet vantevoren een lijstje van kunt maken. Ook dan moet je in je mailserver speciale acties ondernemen zodat deze wel snapt dat alles.mies.com lokaal moet worden afgeleverd, in de default configuratie zal een mailserver aannemen dat alle domeinen die niet met de eigen naam overeenkomen extern zijn, en de mail proberen verder te forwarden. Omdat er een wildcard MX is die naar de server zelf wijst heb je dan een LOOP. Die wordt door een fatsoenlijke mailserver meteen gedetecteerd (“MX record points back to myself”) en door slechte mailservers pas als ie de mail 20 keer naar zichzelf geforward heeft.

1 like

Ik reageerde op jouw “Maar ik zeg: je gaat er uiteindelijk spijt van krijgen. Beter kun je die subdomeinen van te voren vastleggen en een paar expliciete MX records maken@schinagl wil een dynamische functie zoals als aap+noot@mies.com bereiken met een subdomein, dus aap@noot.mies.com. Daarbij is ‘noot’ dynamisch. dus kan je niet van te voren noot.mies.com als MX vastleggen en moet je wel werken met een wildcard MX.