Email komt niet aan

[ITnetadmin]

Okee, dus ik heb een probleem met (minstens 1) emailtje dat niet wil aankomen bij mij.

Situatie:
1) Er was een mail verstuurd -> niet aangekomen
2) Er was een reply-all op gestuurd door iemand anders -> niet aangekomen
3) De mail werd me nog ns geforward door een derde persoon -> niet aangekomen

Persoon 2 wist me te zeggen dat hij een bounce mail kreeg, waarin stond "SPF fail - not authorized (in reply to RCPT TO command)" (error 550 5.7.23).
SPF fail betekent dat mijn mailserver de sending mailserver niet erkent.
Wat raar is omdat de 3 mails door 3 verschillende mensen vanop 3 verschillende mailservers zijn gestuurd.

Andere mails komen wel aan.

Ik vind wel nergens iets concreets terug over het "in reply to RCPT TO command" gedeelte in combinatie met een SPF fail, alleen dat het mogelijk met forwarders te maken heeft.
De mailbox config is inderdaad een forwarder (op domein X, mailserver A); die forward naar een tweede forwarder (domein Y, mailserver B), en die stuurt naar de uiteindelijke mailbox (ook domein Y, mailserver B); maar zoals ik zei, andere mails (op die en andere forwarders) komen wel aan.
Ik lees hier en daar dat mail forwarding kan zorgen voor SPF fails, maar hoe vermijd je dat wanneer je geen controle hebt over de SPF settings van de verzender?

[Splitter]

over het algemeen wil dat zeggen dat je naar het *domein* van de afzender zijn emailadres moet kijken.

dat domein gaat een spf-record hebben dat zegt wie mag sturen vanaf dat domein (meestal zal dat een lijst zijn met bv o365 & google in enzo).
het valt dan vaak voor dat er toch snel even via een bepaald programma of massmailer gemaild zal worden dewelke dat fout doet.
of, bijvoorbeeld, via sophos, dewelke recentelijk een aanpassing gedaan hebben, en waarvan de IPs nog niet whitelisted zijn bij de afzender zijn dns.

het zou me wel sterk verbazen als de afzender in alle 3 de gevallen een ander domein was (dan zou je andere fouten moeten krijgen, of de mail ontvangen),
maar het zou dus prima logisch zijn als de afzender jef@domein1, jaak@domein1 en jos@domein1 zouden zijn (in dat geval zou het probleem dus bij de records van domein1 liggen)

als je me de domeinnamen en headers kan bezorgen, wil ik gerust weleens meekijken, anders is het vooral een beetje gokwerk.

Ik lees hier en daar dat mail forwarding kan zorgen voor SPF fails, maar hoe vermijd je dat wanneer je geen controle hebt over de SPF settings van de verzender?

niet, gezien dat het nut van SPF (en dus "jij bent echt wie jij zegt") zou verslaan
(technisch gezien, als jij zelf volledige controle hebt over *jouw* mailserver kan het wel - whitelisten en dan de spf policy negeren, maar je kan een stuk meer spam krijgen)

[ITnetadmin]

Ja, daarom ook zo raar dat zowel de originele mail, als de reply-all, als de forward, en nu ook een tweede originele mail van dezelfde originele afzender, failen.

Ik heb intussen gevonden dat SPF fails niet ongewoon zijn bij automatische email forwarding, en als de zender zijn SPF/DKIM/DMARC rules zeer strict zet levert dat dus blijkbaar soms problemen op.

Het probleem is dat al mijn incoming mail minstens 1 forward passeert, soms 2, en dat ik dat echt liever niet ga herconfiggen voor 500 forwarders.

[Splitter]

maar, wat waren de afzenders?
behoorden de originele afzender én de reply-all afzender tot hetzelfde domein? want dan is dat dus gewoon 1 probleem waarover het gaat.
en je kan best niet jouw zijde proberen te fixen, maar hun zijde waarschuwen voor een probleem in hun configuratie.

had op het werk overlaatst zulke klant die ons niet meer kon bereiken op onze support, bleek dat zij ook via forwarding werkten (enerzijds voor mailprotection, anderzijds voor mailsignature) en 1 van die 2 had extra IPs toegevoegd, maar dat was bij onze klant niet geupdate in hun spf-record, dus dan werden mails van hen automatisch geblokkeerd.
was opgelost door hun aan te geven dat ze hun dns records moesten checken

Ik vind wel nergens iets concreets terug over het "in reply to RCPT TO command" gedeelte

dit wil gewoon zeggen dat de mailserver de deur dichtgooit voor je iets mag doen.
de externe mailserver zegt "hey ik heb een mailtje voor X", en jouw mailserver zegt gewoon "jij komt er niet in", de meeste zaken die niet doorkomen zullen bij de 'receipt to" worden afgebroken.

SPF fails zijn in principe *niet* gewoon en zijn altijd een gevolg van iets dat ergens foutief ingesteld is.


als je de headers & domeinen niet zou willen delen,
kan je het dan op zijn minst even wat duidelijker schetsen?

ik veronderstel dat dit de situatie gaat zijn:

- originele afzender: [email protected]
- de reply-to afzender: [email protected]
- de forwarded afzender: [email protected]

=> in dit geval moet domeinX.be dus de eigen dns records nakijken

je mag door 10 mailservers gaan, dat maakt niet uit, het is vooral de chain die moet kloppen (ARC),
wat wil zeggen dat als het meerdere mailservers zou passeren, je ook moet zorgen dat elke mailserver:

A) vanaf IPs gaat versturen dewelke in domeinX.be hun spf record staat
B) indien domeinX.be DKIM gebruikt, dient ook elke mailserver onderweg in principe geldige signatures toe te voegen

het heeft dus niets te maken met naar wie gestuurd zal worden -of langs welke weg- zolang de mailservers die zeggen "ik ben domeinX.be en ik stuur deze mail" maar gewoon toegelaten zijn in de spf.

in principe is een forward niet langer een "ik ben domeinX.be" maar een "ik ben domeinY.be en heb dit ontvangen van domeinX.be, voor jou",
wat niet zou mogen falen op de originele afzender zijn dns instellingen

[ITnetadmin]

Nee; de originele afzender en de reply-all zaten op verschillende domains (gmail vs hotmail), degene die wou forwarden was ook een gmail.

Het gaat bij de verzenders dus om prive mailboxen bij grote gratis hosters, geen bedrijfssituaties waar je aan de mailservers of DNS records kan prullen.

Aan mijn kant gaat het om een systeem van email forwarders van verschillende domeinen, die allemaal naar nog een ander domein bij een andere provider forwarden, en dat systeem draait al meer dan 20 jaar zo.

Ik heb geen headers, want ik heb geen mail gekregen.
1 persoon heeft de bounce text gecopypaste in whatsapp, maar dat zijn allen mensen die niet weten wat headers zijn, laat staan hoe ze te bekijken.

Ik lees dus wel dat sommige manieren van forwarden wel alignment breken of SPF failen (bv https://easydmarc.com/blog/email-forwar ... -dkim-spf/ )

[Splitter]

dus het was [email protected] (die verzonden werd vanaf hotmail) en [email protected] (die verzonden werd vanaf gmail) en beide van hun emails kwamen bij jou niet aan?
en in jou geval moest het niet uiteindelijk bij een hotmail of gmail aankomen (die 2 kunnen echt bastards zijn voor deliverability)?

dan is er vermoedelijk aan jouw zijde bij de forwarders een fout - en als het aln "meer dan 20 jaar zo draait" zou ik zeker je antispam checken, want je gebruikt dan misschien ook nog blocklists die ondertussen buiten dienst zijn en mails (random in intervals) weigeren om de mailadmin bewust te maken van dat feit (hum kuch kuch ervaring kuch)

[ITnetadmin]

Geen idee, "mijn" mailservers zijn niet in eigen beheer, maar van 2 mailhost providers.

Verder, ja: [email protected] stuurde een mail en [email protected] stuurde een reply all, daarna stuurde een derde gmailer de mail nog ns als forward.
Niks aangekomen.

Een paar weken geleden stuurde jos nog een mail naar een andere forwarder (op een ander domein / andere mailserver, dit domein staat bij dezelfde provider als het domein van mijn mailbox), en die kwam wel aan.

Zelf een testmail sturen op de forwarder in kwestie komt wel aan.


Added in 14 minutes 6 seconds:
Okee, update:

Sturen ze de mail naar mijn forwarder bij domein X (provider A), komt hij niet aan.

Sturen ze dezelfde mail naar mijn forwarder bij domein Y (provider B, zelfde als waar mijn mailbox op domein Z staat), komt hij wel aan.
Mogelijk breekt de forwarder bij mailserver A dus SPF op een manier die een fail veroorzaakt.


Added in 4 minutes 2 seconds:
Update 2:
Sidenote: gmail users krijgen blijkbaar geen bounces binnen, hotmail users wel.

[ITnetadmin]

Nieuwe update: Provider A gebruikt geen ARC bij het forwarden, en vermoeden is dus dat er idd een of andere SPF/... test failt die vroeger nog slaagde of genegeerd werd. Provider A suggereert dat provider B (waar de mailbox staat) een whitelist kan instellen voor alle forwards vanuit mijn domeinen.
Ik voel een pingpong kastje-muur spelletje aankomen.