tldr; de eerste statusmail v.e. dag naar een alias wordt met een 5.7.1. afgekeurd. Daarna gaat het vervolgens goed. Wat is een mogelijke oorzaak en aanpak voor een oplossing ?
Sinds afgelopen woensdag wordt de eerste statusmail die ik verstuur naar een alias vanaf vanaf één van mijn op naam gestelde Amazon mail-account(s) afgekeurd.
Het betreft een doelalias dat vervolgens uitkomt op mijn freedom.nl mailbox (alias.123@eigenfreedomdomein.nl → mailboxnaam@freedom.nl )
De versturende MTA rapporteert aan mij dan de volgende boodschap:
NB: bij Amazon verstuur ik de mail uit naam van een ander (geverifieerd) mailaccount. Mogelijk dat Freedom de mail weigert in te slikken omdat de from-to header niet overeenkomt met het verzendende (Amazon/MTA) domein. Waarom dan de vervolg emails weer wel worden afgehandeld en worden ontvangen, wordt mij dan erg duister.
Bijzonder is dat een iets later verstuurde email via exact hetzelfde proces, keurig doorkomt op de plek waar die hoort. De mails zelf komt vreemd genoeg probleemloos binnen op mijn gmail account. Ik gebruik - helaas nog steeds ook - Gmail omdat de mail afhandeling door/bij Freedom niet 100% betrouwbaar (b)blijkt.
Inhoud van de statusmail die eerst om 2023/10/07 17:09:02 wordt afgekeurd en een ander om 17:31:03 komt vervolgens wel prima door. Inhoud van de status mail:
Server Name: abcdef
IP Address: x.x.x.x
Date/Time: 2023/10/07 xx:xx:xx
Level: Warning
[External Drive] (Sync) Job Xxxxx–>Xxxxxx finished with warning. Not all files/folders and their attributes are copied!
Herkent iemand dat of is er een suggestie, hoe dit verder te onderzoeken ?
Heeft iemand ervaring bij Freedom dat zij genegen zijn de (mail)logs te - laten - onderzoeken ?
Bij Amazon stopt diagnose simpelweg omdat die een 5.7.1. afkeuring krijgt van Freedom en het daarmee verder klaar is.
Ik laat mijn aliassen in boxnaam@mijndomein.nl terechtkomen.
Dus dat adres aangemaakt in het hoofdaccount onder Domeinen, domein kiezen en dan onder E-mailaccounts.
.
Ik gebruik geen freedom adressen.
Update: Ik bedoel, misschien gaat het fout omdat de mail in het Freedom domein afgeleverd wordt.
Zou het zoiets kunnen zijn?
Iets waar je wel problemen mee kunt krijgen, als het return adres niet gelijk is aan de afzender.
Als het return adres dan ook nog buiten het domein van de afzender ligt, loop je nog meer kans op weigeren.
Ik heb wel eens bij wisselen van een email adres, in return het nieuwe adres gezet.
Niet doen.
Afwijzen gaat met een punten systeem.
Kan best zijn, dat dit vergrijp net op het randje is.
Bij mail problemen laat ik me soms inspireren door dit document.
Thx ga ik 's doorakkeren. Strikt genomen doe ik idd een soort (MS/571) “forged” email (ik verstuur via AmazonSES namens een ander expliciet geverifieerd emailadres).
Het bijzondere is dan, dat dit (sinds Woensdag) alleen gebeurd bij de eerste mail via die omweg. Los hiervan zou het beter zijn dat Freedom de ontvanger van een mailadres zelf laat bepalen of die whatever (foute of van wie dan ook) mail wil ontvangen.
Het lijkt wel een soort van greylisting (Greylisting (email) - Wikipedia), al hoewel daarbij meestal tijdelijke fouten (400-serie) worden gebruikt ipv. 550. Als ze daadwerkelijk greylisting willen implementeren en 550 gebruiken zou dat een foutje bij soverin zijn.
Thx4info & interessant om verder wat gaan Sherlock’en.
Zonet weer de eerste statusmail, afgekeurd.
//–//
Ik herken de vertragingstechnieken maar wist niet dat dit ook een antispam concept was die MTA’s in de gelegenheid stelt (mail)headers te toetsen. De eerste email van een bepaald kenmerk wordt dan een soort sesam-open-u.
Mogelijk dat de 571 ‘opzettelijk’ wordt geforceerd om daarmee een (4xx) herverzending op een later tijdstip te voorkomen. Op die manier is dan een ‘kleine’ horde geplaatst die proberende “wannabes” zal ontmoedigen. Iemand die een 5.7.1. ziet, zal niet snel een nieuwe poging doen.
Ik ga later/morgen de dingen wat anders instellen zodat ik ook weet of tekstinhoud er iets toedoet. Verder kijken of er een tijdsafhankelijkheid is door één van mijn processen - die een status mail veroorzaken - handmatig met een tussenpoos te starten.
De stuk 10+ statusmails komen nu structureel tussen ca 17u00 en 17u45 waarvan de eerste in de serie dus sinds afgelopen Woensdag wordt afgekeurd met die 5.7.1 code.
Allerlei testen gedaan. Het moment, mailinhoud en/of alias dan wel mailboxnaam lijkt niet echt wat uit te maken. Ik krijg vooral de paranoide indruk dat Freedom/Soverin mail inkomende van AmazonSES niet op prijs stelt.
Ter info: Reken maar dat Amazon haar zaakjes 100% bij the book en DKIM zaakjes voor de bakker heeft.
Wat met de inmiddels honderden testjes opvalt, is dat een inkomende status mail eerst soms en nu helemaal niet meer (ongeacht mailbox of alias) wordt ingeslikt. Net of dat iemand zegt, en nu is er genoeg aangerommeld.
Bij een andere provider, is er qua ontvangst totaal geen vuiltje aan de lucht. Het bizarre is dat wanneer ik een willekeurige test mail componeer en die via AmazonSES bij Freedom bij drop, die wel - ook na 10x - weer aankomt.
Enfin, ik ga nog wel verder zoeken maar als dingen niet blijken te werken is het exit met die shit.
Misschien zeg ik hier iets voordehandliggends, maar heb je gecheckt of het SPF TXT record van jouw domein in kwestie (nog) “include:amazonses.com” bevat? Wellicht dat een greylisting mechanisme inspringt omdat er geen (kloppend) SPF record wordt gevonden.
Tenminste, als je dit domein ook als afzender gebruikt. Zo niet dan moet je dat checken voor het gebruikte afzenderdomein.
Thx. ik doe geen eigen mail noch rommel(de) ik met MX/SPF/TXT records etc.etc.
Het irritante is dat met exact hetzelfde functie/proces, mail wel en een ander niet wordt afgeleverd. Ik krijg een gevoel van spoken jagen. Tijd, onderwerp, locatie, betrokken mailbox of alias; lijkt allemaal geen invloed te hebben voor de statusmail die ik via AmazonSES wil afleveren in mijn mailbox(en) bij Freedom (en, zo blijkt, ook Soverin).
//–//
Ik ben met testen zover gekomen dat alleen zg “confirmatie” status mails (uit dezelfde bron en functie) lijken te worden geweigerd. Zg. “warning” alsmede ook “hello world” statusmails worden gelukkig WEL ontvangen.
Waarom gisteravond ineens alle mails werden geweigerd en vanmiddag OK gingen, is mij onduidelijk. (Gremlins ?)
Mailopmaak met OK wordt door mijn andere providers prima ontvangen maar expliciet dus NIET bij Freedom (en ook Soverin):
Server Name: xxxxxxxxxxxxxxxxxx
IP Address: xxx.xxx.xxx.xxx
Date/Time: 2023/10/09 13:30:43
The synchronization of xxxxxxxxxxxxxxxxxxxxxx finished.
Folder Pairs : 1
Total File(s) : 48319
Total Folder(s) : 3192
Skipped Files : 48303
Backed-up Files : 3
Total File Size : 62.01 GB
Average Transmit Speed: 25.45 KB/s
Mailopmaak via hetzelfde status een WARNING als status bevestiging geven, worden dus zoWEL afgeleverd bij Freedom, Sovern en bij andere providers:
Server Name: xxxxxxxxxxxxxxxxxx
IP Address: xxx.xxx.xxx.xxx
Date/Time: 2023/10/09 13:30:41
Level: Warning
xxxxxxxxxxxxxxxxxxxxxx finished with warning. Not all files/folders and their attributes are copied!
FYI: Mijn bericht dat de eerste email werd afgekeurd is daarmee feitelijk onjuist. Alleen mails met expliciet goed verlopen Rsync status, worden niet afgeleverd.
De eerste email die in beginsel niet werd afgeleverd was toevallig een expliciete bevestiging dat iets op orde was. Voor andere sync-processen, (ook elders) stuur(de) ik geen confirmatie(s) dat iets OK was. Waneer ik de volgorde (goed/fout) omdraai, wordt die status (ook van andere OK’s) conform en structureel geweigerd.
Puur als mailfunctie, dat bij mij een proces wel goed is verlopen, is inmiddels met een kromme omweg als “fout” opgelost.
AmazonSES stuurt mij de informatieve statusmail - die dus niet kon worden afgeleverd bij Freedom/Soverin - via een fout-rapport als attachement naar de weigerachtige mailbox. Het meegezonden “xxxx.eml” bestand bevat alsnog de statusinformatie van een goed verlopen proces (dat ik wil registreren).
Ik moet nu alleen het attachment peuren.
Helaas niet goed voor mij reputation metrics en complaint rate. Amazon telt mails die niet kunnen worden afgeleverd als “bad attitude”. Voor het (mail)rapport van zowel een niet als wel afgeleverde mail, moet betaald worden.
Kosten vallen mee, iets van $0.10 per 1000 e-mails. Dus voor mij op maandbasis een extra €0,20 en verder de sop de kool niet waard om er van te eten.
Ik weet ook niet hoe ik dit verder echt inhoudelijk kan (laten) oplossen en gooi de handdoek in de ring.
?)