Incidenteel ipv6 probleem ontvangst gmail servers, rond 8.00

[fortfort]

Ik ben bekend met de ipv6 gmail richtlijnen, maar krijg voor één van de domeinen waar mail wordt verstuurd door een ander ipv6 adres het maar niet voor elkaar om ALTIJD goed via ipv6 te verzenden. Rond 8.00 gaat dit soms mis (en alleen bij google) (ik verstuur ongeveer 100 mails per dag)

Wat mij opvalt is de line feed in het ipv6 adres, Iemand een idee?

<[e-mail]> for [e-mail]
2023-12-10 08:00:08 1rCDnG-0000000Cswc-19DJ ** [e-mail] F=<info@> R=lookuphost T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:4025:402::1b] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes: SMTP error from remote mail server after end of data: 550-5.7.26 This mail has been blocked because the sender is unauthenticated.\n550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.\n550-5.7.26\n550-5.7.26 Authentication results:\n550-5.7.26 DKIM = did not pass\n550-5.7.26 SPF [domain.nl] with ip: [3a02:1c8:cb0a:81:5054:ff:fe3d:\n550-5.7.26 4f8d] = did not pass\n550-5.7.26\n550-5.7.26 For instructions on setting up authentication, go to\n550 5.7.26 https://support.google.com/mail/answer/81126#authentication d2-20020a50ea82000000b0054cf80f1568si2573909edo.645 - gsmtp

[valkenier]

SPF faal en DKIM faal. Dan zou ik hem ook weigeren. Van dat IPv6 adres kan iktrouwens niks vinden

[DataGhost]

Er zit geen line feed in dat adres, het laatste blokje is gewoon 0000 en omdat er al zeven blokjes voor staan volgt er geen dubbele dubbele punt maar gewoon een enkele. Verder inderdaad als SPF en DKIM falen zal je eerst moeten gaan uitzoeken waarom dat zo is en dat lijkt me gewoon regels lezen. Kan je vanaf diezelfde host/server op andere tijden dan wel mailen? Aangezien je het over "een ander ipv6 adres" hebt lijkt me dat dat adres gewoon niet mag sturen voor dat domein.

[fortfort]

DataGhost schreef op zondag 10 december 2023 @ 23:54:
Er zit geen line feed in dat adres, het laatste blokje is gewoon 0000 en omdat er al zeven blokjes voor staan volgt er geen dubbele dubbele punt maar gewoon een enkele. Verder inderdaad als SPF en DKIM falen zal je eerst moeten gaan uitzoeken waarom dat zo is en dat lijkt me gewoon regels lezen. Kan je vanaf diezelfde host/server op andere tijden dan wel mailen? Aangezien je het over "een ander ipv6 adres" hebt lijkt me dat dat adres gewoon niet mag sturen voor dat domein.

[3a02:1c8:cb0a:81:5054:ff:fe3d:\n550-5.7.26 4f8d]

Het laatste deel van ipv6 adres is 4f8d
En zoals ik aangaf gaat het versturen vanaf inderdaad dit ipv6 (anoniem gemaakt) gaat altijd goed. Al jaren. Maar dus heel soms niet. En gek genoeg rond 8.00 sochtends en alleen bij gmail.

[valkenier]

Je lijkt de specifieke opmerkingen over SPFen DKIM niet serieus te nemen, je gaat er in elk geval niet op in, want het ging jaren goed. Nu dus niet. Wij kunnen dit niet verder troubleshooten, als je het IPv6 adres hebt verminkt, en geen domein prijsgeeft.

Wat wel een beetje vreemd is is dat die foutcode n550-5.7.26 steeds terugkomt op gekke plaatsten in die bounce.

[ Voor 18% gewijzigd door valkenier op 11-12-2023 08:54 ]

[fortfort]

Spf faalt omdat line feed in de ipv6 record lijkt te zitten bij de ontvangende partij (gmail). Tuurlijk faalt die dan. Dkim bij verzenden mail vanuit ander ipadres uit naam van is niet van toepassing. En ook niet nodig.

[ofc]

fortfort schreef op maandag 11 december 2023 @ 08:55:
Spf faalt omdat line feed in de ipv6 record lijkt te zitten bij de ontvangende partij (gmail). Tuurlijk faalt die dan. Dkim bij verzenden mail vanuit ander ipadres uit naam van is niet van toepassing. En ook niet nodig.

Die newline heeft niets met het probleem te maken. Er wordt een nette foutmelding geproduceerd waarin newlines gebruikt worden om het leesbaar te maken:

code:

2023-12-10 08:00:08 1rCDnG-0000000Cswc-19DJ ** [e-mail] F=<info@> R=lookuphost T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:4025:402::1b] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes: SMTP error from remote mail server after end of data: 
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [domain.nl] with ip: [3a02:1c8:cb0a:81:5054:ff:fe3d:
550-5.7.26 4f8d] = did not pass
550-5.7.26
550-5.7.26 For instructions on setting up authentication, go to
550 5.7.26 https://support.google.com/mail/answer/81126#authentication d2-20020a50ea82000000b0054cf80f1568si2573909edo.645 - gsmtp

Zoals de anderen al aangaven: DKIM en SPF falen. M.b.v. de huidige beperte en bewerkte informatie is niet te achterhalen waarom dat gebeurt.

[fortfort]

ofc schreef op maandag 11 december 2023 @ 10:29:
[...]


Die newline heeft niets met het probleem te maken. Er wordt een nette foutmelding geproduceerd waarin newlines gebruikt worden om het leesbaar te maken:

code:

2023-12-10 08:00:08 1rCDnG-0000000Cswc-19DJ ** [e-mail] F=<info@> R=lookuphost T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:4025:402::1b] X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes: SMTP error from remote mail server after end of data: 
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [domain.nl] with ip: [3a02:1c8:cb0a:81:5054:ff:fe3d:
550-5.7.26 4f8d] = did not pass
550-5.7.26
550-5.7.26 For instructions on setting up authentication, go to
550 5.7.26 https://support.google.com/mail/answer/81126#authentication d2-20020a50ea82000000b0054cf80f1568si2573909edo.645 - gsmtp

Zoals de anderen al aangaven: DKIM en SPF falen. M.b.v. de huidige beperte en bewerkte informatie is niet te achterhalen waarom dat gebeurt.

Er is geen reden om de ip6 op deze plek te onderbreken naar nieuwe line.

[DataGhost]

En toch heeft het tussenliggende systeem besloten dat er op die plek een line feed moet komen vanwege whatever. Er kan per definitie geen line feed in het adres zitten. De andere kant komt aan dat adres door het uit de header van het netwerkpakket te halen en dat is 16 bytes lang, zonder dubbele punten enzo. Het wordt niet als een volledige human-readable string aangeleverd, dat slaat nergens op. Je kan dus niet tegelijkertijd een IP hebben met een vol laatste blokje en een line feed erin want dan heb je al minimaal 17 bytes nodig. Het enige wat jij ziet is de response van de server die in 1 "foutregel" gezet is, zoals hierboven al netjes zichtbaar gemaakt voor je.

Dus moet je in je SPF/DKIM gaan zoeken naar mogelijkheden waarom het om precies 8:00 niet zou werken. Heb je SPF ingesteld staan? Heb je DKIM ingesteld staan? Misschien heb je een gare DNS-server die rond dat tijdstip niet werkt, of oude informatie teruggeeft? Gebruikt whatever script dat om 8 uur draait je normale mailserver, of praat het zelf direct SMTP met de ontvangende kant? Als je datzelfde script op een ander tijdstip uitvoert, werkt het dan wel (note dit is niet hetzelfde als op een ander tijdstip een random mailtje sturen)?

[ Voor 11% gewijzigd door DataGhost op 11-12-2023 11:59 ]

[fortfort]

Dank je wel DataGhost om verder te kijken dan alleen roepen dat spf record niet goed is, ik heb net toevallig ook zowaar reactie van google die ook eens verder in de materie is gedoken.

Het blijkt dat via hun DIG systeem (https://toolbox.googleapps.com/apps/dig/#TXT/)
DNS records anders worden uitgelezen dan via bv mxtoolbox of welke dan ook. En wat blijkt in het spf record wordt include:s" "erver.domain.nl uitgelezen ipv van server.domain.nl. Google is er mee bezig.
En voor de goede de dns van antagonist wordt hier gebruikt, en in mijn spf record staat dus server.domain.nl.
Antagonist krijgt dus nu ook huiswerk

[GarBaGe]

In principe heeft je IPV6 niets te maken met DKIM en SPF.
DKIM en SPF zijn DNS records op een domein naam. (TXT records)
Aan dit domein naam, kan je ook IPV4 (A record) en IPV6 (AAAA record) adressen hangen (optioneel), maar stel die dit een email-only domein is, dan hoeft dit niet.

Edit: je kan ook Dmarcian gebruiken als externe tool om je SPF en DKIM te testen voor een gegeven DNS: https://dmarcian.com/

[ Voor 18% gewijzigd door GarBaGe op 11-12-2023 12:31 ]

[DataGhost]

Nja je wilt het domein niet vertellen maar ik ben reuze benieuwd naar wat je SPF-record dan precies is, en zou dat het liefst zelf uitlezen met mijn eigen tool om mogelijke oorzaken te vinden, maar goed. Ook daar kan niet zomaar een random spatie/linefeed/wathetdanookis in komen in principe. Dat zou ik als eerste in jouw record (vreemd teken? zero-width space?) en daarna in jouw DNS-server (rare bug, of een compleet achterlijk gebruik van line wrapping?) zoeken, niet bij Google om eerlijk te zijn. Informatie over de precieze en gehele oorzaak zou voor anderen ook van toepassing kunnen zijn.

[ Voor 6% gewijzigd door DataGhost op 11-12-2023 12:45 ]

[valkenier]

Je kan wel zeggen dat wij maar wat roepen dat SPF niet klopt, maar we lezen gewoon netjes de foutmelding.

Ik krijg nu bv zomaar het vermoeden dat je SPF record langer is dan is toegestaan. (max 255). Maar dat mogen we niet zien.

[DataGhost]

Ook verklaart deze uitleg nog niet echt waarom het alleen rond 8 uur 's ochtends gebeurt en niet op andere momenten.

[DataGhost]

Net een DM gekregen met het domein, output van een query maakt het een stuk duidelijker:

domein.nl. 3600 IN TXT "v=spf1 a mx ip4:aa.bb.cc.dd ip6:aa:bb:cc:dd:ee:ff:gg:hh ip4:aa.bb.cc.dd/21 ip6:aa:bb:cc::/48 ip4:aa.bb.cc.dd/22 ip6:aa:bb:c" "c::/48 include:_spf.google.com ~all"

Dat is dus iets anders dan dat er

iets:and" "ers

in het record zou staan, dat is namelijk niet zo. Dit is een multi-line TXT record waar juist het " "-gedeelte helemaal geen deel van uitmaakt. Dat is prima volgens de RFC, daarmee kunnen SPF-records langer dan 255 tekens gemaakt worden en alle regels in het TXT-record horen aan elkaar geknoopt te worden zonder spaties ertussen. Dan lijkt het inderdaad op een bug bij Google, aangezien dat hier niet gebeurd is. Dus of ze pakken alleen de eerste regel, wat een incompleet/ongeldig SPF-record zou zijn, of ze plakken ze niet goed aan elkaar.

Maar, in principe prima volgens de RFC, alleen het punt waarop het record gesplitst is in meerdere regels is hoogst ongelukkig, zo midden in een IP-adres. Helemaal omdat het complete record maar 186 bytes lang is, dus als er ergens in dit topic geen aanleiding was voor een nieuwe regel was het hier wel En nogmaals verklaart het niet waarom het dan alleen op een bepaald tijdstip mis zou gaan.

[valkenier]

@DataGhost OK, Heb je ook het bewuste IPv6 adres in de DM, en matcht dat met het SPF record?
Ik gok dat het deze is? ip6:aa:bb:c" "c::/48 Dan zou ik die knip uit het IPv6 adres halen, denk ik.

Ook lees ik hiervan

in het spf record wordt include:s" "erver.domain.nl uitgelezen ipv van server.domain.nl.

niks terug in het record, alleen IP adressen. (wel een include voor spf van google).

en DKIM? en DMARC?

[DataGhost]

Dat zie ik ook niet terug maar ik vermoed dat dat gewoon een zeer ongelukkige manier van censureren is geweest. Ik zie zelf de noodzaak tot het censureren ook niet echt, het is een heel normale site van een heel normaal bedrijf. De enige include is _spf.google.com. DKIM kan ik niet zomaar checken volgens mij want ik ken hun selectors niet. DMARC heeft policy none.

Het bewuste IPv6-adres is de eerstgenoemde vermoed ik (erg veel overeenkomsten), dus die is niet "verknipt". Ik had dit nog niet gecontroleerd maar dat lijkt wel een server van een derde partij, dus het kan ook zo zijn dat er daar aan configuratie iets niet lekker staat. Maar volgens mij maakt dat met een werkend SPF-record niet zoveel uit.

[fortfort]

De huidige DNS SPF record is inderdaad anders dan toen we begonnen, er wordt nu getest bij Antagonist. Op dit moment nog steeds via DIG geeft het een samengesteld record met " ". Tevens scripts aangepast om niet meer om 8.00 te beginnen. Eens kijken wat dat doet. Zal later terugkoppelen.

[ Voor 32% gewijzigd door fortfort op 11-12-2023 15:14 ]

[DataGhost]

Ze splitten volgens mij gewoon elke 150 tekens. Je kan misschien zelf extra spaties toevoegen zodat er in ieder geval geen IP's gesplitst worden maar in hoeverre dat wat uitmaakt op het geheel weet ik niet. Also als je nu meerdere verschillende dingen tegelijk wijzigt kan je straks de uiteindelijke oorzaak niet goed achterhalen.

[ Voor 23% gewijzigd door DataGhost op 11-12-2023 15:22 ]

[fortfort]

dat laatste heb je helemaal gelijk in, ik weet vrij zeker dat het een combinatie is van meer dan 150 tekens en Antagonist en ipv6. nu nog de waarom rond (of eigenlijk op) 8.00. Wat ik nu kan verzinnen is net op dat moment een dns refresh vanuit antagonist

[valkenier]

DataGhost schreef op maandag 11 december 2023 @ 14:22:
Dat zie ik ook niet terug maar ik vermoed dat dat gewoon een zeer ongelukkige manier van censureren is geweest. Ik zie zelf de noodzaak tot het censureren ook niet echt, het is een heel normale site van een heel normaal bedrijf. De enige include is _spf.google.com. DKIM kan ik niet zomaar checken volgens mij want ik ken hun selectors niet. DMARC heeft policy none.

Het bewuste IPv6-adres is de eerstgenoemde vermoed ik (erg veel overeenkomsten), dus die is niet "verknipt". Ik had dit nog niet gecontroleerd maar dat lijkt wel een server van een derde partij, dus het kan ook zo zijn dat er daar aan configuratie iets niet lekker staat. Maar volgens mij maakt dat met een werkend SPF-record niet zoveel uit.

Ongelukkig censureren zou kunnen in dit geval.
En krijg jij wel een “normale reactie” met dig voor het domein?
DKIM kun je idd niet testen zonder selectors te weten. Ik dacht dat jullie die wellicht hadden uitgewisseld.

[DataGhost]

valkenier schreef op maandag 11 december 2023 @ 18:20:
[...]

En krijg jij wel een “normale reactie” met dig voor het domein?

Output van "dig <domein> TXT" staat in de quote in DataGhost in "Incidenteel ipv6 probleem ontvangst gmail servers, rond 8.00" Blijft verder je definitie van "normale reactie" over, volgens de RFC is het een normale reactie en ik kan hem zelf goed lezen maar er zijn redenen om het geen normale reactie te vinden waarbij je een deel van de schuld bij beide partijen kan leggen.