Nut van een fallback mailserver

[Briolet]

Ik zie wel eens een verwijzing naar deze handleiding voor het inrichten van een fallback mailserver. Ik vroeg me altijd al af of het nut had omdat er ook nadelen aan zitten. Zonder fallback server proberen de verzenders toch al 2 à 3 dagen om de mail alsnog af te leveren.

Het is me vorig jaar 1x gebeurd dat mijn externe mail hoster (dataweb.nl) een storing had en de mail via hun eigen backup server binnenkwam. Dit mailtje was als spam gemarkeerd. In de header kijkend kwam dit doordat er een SPF hard-fail optrad. Bij een SPF test wordt er gekeken of het IP adres van de smtp zender wel op de lijst met toegestane IP adressen staat. Komt die mail via een falback server binnen, dan kan hij eigenlijk per definitie niet op de toegestane lijst van de verzender staan.

Vandaag kwam ik nog een andere reden tegen om geen tweede MX record aan te maken. Als die fallback server niet goed beveiligd is, is dat een gemakkelijker prooi voor spammen.

Maar vooral de eerste reden zie ik als een probleem omdat de MailServer nu ook SPF en DMARC controles kan uitvoeren. Als de afzender zijn mail via deze protocollen beveiligd, kan de mail bouncen als hij via een fallback server binnenkomt.

Of mis ik hier iets??

[Robert Koopman]

Ik mis de Fall Back server eigenlijk ook niet.
Mail komt inderdaad met vertraging gewoon alsnog binnen.
Misschien krijgt de verzender wel een bericht dat zijn mail niet afgeleverd kan worden en staat dat onprofessioneel?

[Briolet]

Ik denk dat het goed aankomen belangrijker is dan het professioneel uitzien. Zeker als fallback servers voor bouncing mail kunnen zorgen wat in mijn opinie erger is.

Als ik met het 'host' command diverse sites bekijk, zie ik diverse aanpakken. Mijn externe mail provider geeft

Briolet$ host -t MX dataweb.nl
dataweb.nl mail is handled by 100 fallback.dataweb.nl.
dataweb.nl mail is handled by 10 mail2.dataweb.nl.

De naam geeft al aan dat ze een fallback server gebruiken en uit ervaring heb ik gemerkt dat als die mail doorstuurt naar de echte server, hij als spam gekenmerkt kan worden bij beveiligde mail.

Ziggo daarentegen doet het anders:

Code: [Selecteer]

Briolet$ host -t MX ziggo.nl
ziggo.nl mail is handled by 50 mx.tb.mail.iss.as9143.net.
ziggo.nl mail is handled by 50 mx.gn.mail.iss.as9143.net.
Dus twee gelijkwaardige servers (identieke prioriteit). Er zal random een gekozen worden wat een soort van load balancing genereert. Of eigenlijk kiest de ontvanger niet random, maar de DNS server stuurt ze al in random volgorde naar de opvrager.

Idem doet Microsoft:

Code: [Selecteer]

Briolet$ host -t MX hotmail.com
hotmail.com mail is handled by 5 mx3.hotmail.com.
hotmail.com mail is handled by 5 mx1.hotmail.com.
hotmail.com mail is handled by 5 mx4.hotmail.com.
hotmail.com mail is handled by 5 mx2.hotmail.com.

Bij google vind ik wel verschillende prioriteit:

Code: [Selecteer]

Briolet$ host -t MX gmail.com
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
Zij hebben 1 hoofd server en wel 4 backup servers. Maar ik gok dat dit geen fallback servers zijn, maar allen servers die direct op het gebruikers account afleveren, net als bij Microsoft en Ziggo.

[Briolet]

Er is nog een argument om juist geen "Fallback Mailserver" te gebruiken en dat is het verminderen van spam.

Eén van de methodes om spam te versuren is het indirect versturen. De spammer stuurt de mail eerst naar een betrouwbare mailserver , maar met een foutieve afzender. Die foutieve afzender is eigenlijk het beoogde doel.

De mailserver kan niets met deze mail en stuurt hem dan terug naar de gespoofde afzender. Deze krijgt nu een mailtje die van jouw nas lijkt te komen en jij wordt aangemerkt als spammer in blacklistings.

Dit soort mailbounces worden normaal al gedurende de smtp connectie afgehandeld waardoor deze mail niet eens geaccepteerd wordt, als de server goed geconfigureerd is. Bij een fallback server, zal deze server deze mailtjes echter wel aannemen. Als je eigenlijke server weer on-line is, krijgt hij die mailtjes en kan ze niet meer weigeren. Daarna zal hij de mailtjes terugsturen naar het retour adres. En dat is nu juist niet de verzender, maar het beoogde doel voor de spam.

Iets meer over dit soort spam vond ik hier, voor een Exchange server. En dan met name het volgende stuk dat halverwege staat:

Why is my secondary MX a problem?
If it never relays any spam to your primary one, there is nothing wrong with it. However, in most cases, the secondary MX is hosted by an ISP or other third-party, it is not secured against spam and cannot validate the recipients. Thus, it will relay everything (including spam and emails sent to non-existent addresses) to your primary MX.

Since the secondary MX acts as a non-transparent relay source, the Before Arrival filtering of ORF cannot be used, only On Arrival. The email could have been rejected at the SMTP protocol level during the original SMTP conversation only (between the original sender and the secondary MX). The only way to notify the sender now about the failed delivery is sending an NDR, and you know where that leads: backscatter.