Hallo @AntiFTW
Ik mis het stukje van de CA certificaten, staat dat wel in je main.cf?
# where to find CA certificates
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
Wat komt er dan wel in je logs te staan?
Misschien moet je de logging meer uitgebreid (verbose) zetten voor postfix, zie deze pagina: https://www.postfix.org/DEBUG_README.html
Hallo @GeSp,
Bedankt voor de snelle reactie.
Wat betreft het Certificaat, die had ik inderdaad over het hoofd gezien, en nadat ik die had toegevoegd kreeg ik wel een wat duidelijkere foutmelding waar ik iets mee kon (“warning: SASL authentication failure: No worthy mechs found”), waarna ik er na een korte zoektocht achterkwam dat er nog iets nodig was:
smtp_sasl_security_options = noanonymous
En toen ik daarna nog eens probeerde te mailen kwam de mail aan.
Dus het originele probleem is verholpen, dank daarvoor!
Echter, zie ik nu wel een andere issue. Wanneer ik hem test met mailtester.com zegt hij dat er iets in de DKIM niet klopt: “Before using DMARC, you should make sure the domains used in the Envelope From (e.g., Return-Path or Mail-From), the "Friendly" From (i.e., "Header" From) and the d=domain in the DKIM-Signature are the same”.
Heeft er dus mee te maken dat het DKIM domein kpnmail.nl is, en de FROM header mijn eigen domein heeft. Maar aangezien de betreffende DKIM record van KPN is en niet van mij, kan ik deze dus niet aanpassen. En het FROM domein aanpassen naar kpnmail.nl lijkt me ook niet echt de bedoeling?
Hallo @AntiFTW
De sasl_security regel miste i.d.d. ook, had ik ook overheen gekeken.
Aan DKIM kan je niets veranderen om dat te laten kloppen.
Als je zelf ook nog een DKIM signature toevoegt zal die ook niet meer kloppen, daar zijn wel mechanismes voor zoals ARC maar volgens mij is dat bij de KPN mailservers niet geïmplementeerd, tijdje geleden i.i.g. nog niet.
Heb je een DKIM, SPF en/of DMARC record in de DNS van je domein ingesteld?
Als mailen nu werkt zou je het ook zo kunnen laten, misschien wel beter om een SPF record in te stellen met daarin de include van de KPN mailservers.
Hallo @GeSp,
Ok, dat is wel jammer dan, dan vraag ik me af wat erger is. een niet goed werkende DKIM of de PTR die niet niet goed staat, aangezien mailtester.com je in beide gevallen wel een 10 geeft, met warnings.
Er zijn inderdaad geldige SPF/DKIM/DMARC records voor mijn domein, en bij de SPF zit een include voor de kpn server:
include:spf.ews.kpnxchange.com
Dus dat zou allemaal goed moeten zijn.
Bedankt voor de link naar ARC. Zal daar eens wat over lezen, en ben ook wel benieuwd wat KPN hierover te zeggen heeft? Lijkt me niet echt wenselijk dat de DKIM records niet kloppen, aangezien je dan in feite in naam van KPN spam aan het versturen bent. Daarnaast is het feit dat email “werkt” nogal relatief, en zijn grote email providers (Outlook/Gmail) erg picky in mijn ervaring.
Hallo @AntiFTW
Een niet kloppend PTR record zou eigenlijk geen probleem mogen zijn als je zonder relayhost wil mailen, bij Outlook/Gmail was dat geen probleem toen ik IPv6 aanzette op de mailserver en toen wel een kloppend IPv4 PTR record had maar nog geen IPv6 PTR record had laten instellen.
De enige die ik ben tegengekomen die zonder kloppende PTR records botweg de mail weigert is mijndomein, dus als je naar iemand wil mailen die daar zijn mail heeft ondergebracht dan heb je een kloppend PTR record nodig voor IPv4 (en IPv6 als je dat gebruikt).
Bij KPN kan je ook je eigen domein e-mailaccounts instellen bij mail, dan klopt het DKIM record ook niet, dat zou dus geen probleem moeten zijn.
Zie deze thread over eigen domein e-mailaccounts toevoegen:
Je kan het beste kiezen voor geen kloppend DKIM record lijkt mij, in je DMARC record zou je dan p=none moeten gebruiken.
DKIM klopt prima, enkel niet in relatie tot DMARC daar signing domain dan gelijk moet zijn aan de From: .
Als je een DMARC record wil voeren zal je simpelweg niet via ons moeten versturen. Dit kan rechtstreeks via de verbinding, hoewel je tegen issues aan kan lopen omdat je een residential IP hebt (ie, een eindgebruiker IP).
De rDNS is inderdaad ook niet aan te passen maar klopt wel (ie, er is een geldig A record voor je PTR). Je kan de HELO van je server aanpassen naar <IP.fixed.kpn.net waarna het driehoekje HELO - PTR - A netjes rond is.
Nog even als response op @GeSp : P=None is een test instelling zodat je rapporten krijgt over mails waarbij de DMARC check fout gaat. Als permanente oplossing kan je dan net zo goed geen DMARC voeren daar de uitkomst van een DMARC check bij P=None genegeerd word.
@Dennis ABD,
Bedankt voor de reactie.
Ik kan inderdaad rechtstreeks mailen maar dan loop je tegen het issue aan dat je de PTR niet kan aanpassen, en dan krijg je daar gezeur mee.
Is het daarnaast zomaar mogelijk om de HELO aan te passen zonder dat dat ergens anders iets sloopt? Als ik namelijk opzoek hoe ik de HELO zou moeten aanpassen voor postfix dan heeft hij het over het aanpassen van de hostname (https://www.ionos.com/help/server-cloud-infrastructure/server-administration/configuration-of-the-helo-entry-of-your-mail-transfer-agent-mta/)
sudo echo 'mail.example.org' > /etc/mailname
sudo postconf -e myhostname=mail.example.org
En om heel eerlijk te zijn betwijfel of ik dit zomaar kan doen, Ik weet namelijk dat ik daar bij de initiele configuratie niet zomaar aan mocht zitten.
Maar omdat ik ook niet alle waarheid in pacht heb, besloot ik het toch eens te proberen, en nu krijg ik ineens een 6.3 bij mailtester.com met de melding:
“Relay HELO'd using suspicious hostname (IP addr 2)”
Ook als ik in mijn eigen SpamAssassin logs kijk, zie ik dat hij niet blij is met deze instellingen en krijg ik een significant hogere spamscore.
Dus dit is niet toegestaan, en levert meer problemen op. De reverse DNS klopt nu wel, maar dit is geen goede oplossing. Graag geen halve oplossingen delen, dat zorgt alleen maar voor verwarring.
Daarnaast bedankt voor het punt dat je maakt met betrekking tot de DMARC, een policy van none heeft niet zoveel (lees: geen) zin.
Suspicous hostname zaken ga je blijven houden, los van hoe je de HELO instelt, het rDNS is namelijk generiek. Er zijn partijen die checken of de HELO, A en PTR overeen komen en, zo nee, de mail weigeren of knijpen. Andere partijen zullen bij enkel al een generic rDNS de boel weigeren. Hoewel het kan is een thuis aansluiting eigenlijk simpelweg niet geschikt om serieus een mailserver te draaien en te verwachten dat het altijd werkt. Als dat het doel is ben je beter af met een VPS ergens waarbij wel mogelijkheden zijn tot het aanpassen van de rDNS en het plaatsen van een eigen DKIM signature ten behoeve van DMARC.
Beetje raar antwoord maar goed.
Eerst claim je een oplossing te hebben - die in feite slechter is dan de oplossing die wij zelf hadden gevonden - en nu zeg je dat het eigenlijk niet op een goede manier op te lossen is?
Is er ook iemand die er wel verstand van heeft en niet zomaar dingen roept?
En het feit dat het niet geschikt is, is gewoon beleid van jullie. De mogelijkheid om de PTR aan te passen zou genoeg moeten zijn, en wat ik op het forum lees is dat een bewuste beleidsbeslissing geweest om dit af te schaffen.
Het lost de problemen van het niet matchende PTR op, dat was het punt. Daar had ik mogelijk duidelijker in kunnen zijn.
Dat was mijn vraag niet. Is er iemand die wel verstand van zaken heeft en mij wel zinnige antwoorden kan geven in plaats van een non-oplossing die meer kapot maakt dan het daadwerkelijk oplost?
Of is het antwoord van KPN, als je een eigen mailserver wilt, dat ondersteunen wij niet? In ieder geval niet volgens industry standards? Ben daar dan gewoon eerlijk over.
Is dit officieel beleid? Want ik kreeg de indruk van een collega van u toch het idee dat jullie deze service wel leverden via een relay.
Hier de collega in kwestie:
Is er iemand die wel verstand van zaken heeft
Als er iemand binnen het bedrijf is die verstand heeft van inhoudelijke techniek op e-mailvlak, met alle bijbehorende beveiligingsstandaarden en antispam-oplossingen, dan is het Dennis wel, dus mocht je dat anders zien, dan kan ik niet anders dan concluderen dat je de boel verkeerd inschat.
Of is het antwoord van KPN, als je een eigen mailserver wilt, dat ondersteunen wij niet? In ieder geval niet volgens industry standards? Ben daar dan gewoon eerlijk over.
Precies dit, en voor zover ik weet is dat bij alle providers ook wel zo. Zoals Dennis al aanstipt is een thuisaansluiting (bij welke provider dat ook is) niet geschikt om een mailserver op te draaien. Het kan wel, maar daar horen dan soms de nodige ongemakken bij. De uitgaande mailserver mag, zoals genoemd, als relay voor je mailserver gebruikt worden, maar die mailserver is hoofdzakelijk ingericht voor het standaard gebruik van de meeste KPN klanten. Dat dit ook mogelijk is is mooi meegenomen, maar heeft niet de hoogste prioriteit voor een ISP.
Hallo @Raymondt,
Okee duidelijk, dan weet ik voldoende. Vind ik het nog steeds wel een beetje vreemd dat de man met verstand van zaken dat een oplossing aandraagt die meer kapot maakt dan dat het daadwerkelijk fixed. Maar goed, dat terzijde.
Daarnaast vind ik de opmerking dat een thuisaansluiting niet geschikt zou zijn voor het draaien van een mailserver wat apart, aangezien de PTR aanpassing daadwerkelijk het enige wat nodig is om het volledig volgens industry standards te laten draaien.
Ik kan me voorstellen dat jullie streng zijn dat er geen spam gestuurd wordt vanaf jullie netwerk, maar ik snap de weerstand niet echt tegen een fatsoenlijk ingerichte mailserver. Zo te zien zijn er genoeg mensen die er gebruik van willen maken, al snap ik dat het niet in verhouding staat tot jullie totale klanten.
Overigens hoorde ik ook ergens dat het bij een zakelijk abbonement wel mogelijk zijn om de PTR aan te passen, ik weet niet of dit klopt?
Tot slot is voor mij de oplossing die @GeSp voor nu ook afdoende als jullie zeggen dat de DKIM mismatch geen issue is, en de mails gewoon aankomen.
Dennis gaf je een antwoord op je specifieke vraag, het enige antwoord dat er mogelijk is. Of dat de beste oplossing overall is is niet gezegd, maar ook niet gevraagd.
Wanneer je installatie voldoet aan alle industry standaarden, betekent dat nog steeds niet dat het verstandig is om je mailserver op een thuisaansluiting te draaien. Je blijft namelijk met een ip-adres verzenden die als 'residential ip' te boek staat. Dat kan invloed hebben. Op een thuisverbinding zit bij eventuele storingen geen SLA, zoals die er bijvoorbeeld op netwerken in datacentra wel is. Tevens moet je voor een hoop zaken het wiel opnieuw uit gaan vinden (zoals bijvoorbeeld als het gaat om spamfiltering). Dat hoeft niet persé erg te zijn, omdat het bijvoorbeeld een hobby is, maar maakt dat het gelijk verstandig voor een goeie mailafhandeling? Zo zijn er nog tal van redenen op te noemen waarom het naast het PTR dingetje onverstandig is, of kan zijn.
Er is overigens geen enkele weerstand tegen een fatsoenlijk ingerichte mailserver. Maar (er vanuitgaande dat je hier doelt op het mogelijk maken van het instellen van een PTR) er is vanuit het bedrijf wel een keus gemaakt dat dit een dienst is waar we niet in willen investeren om dit in stand te houden en te onderhouden.
De kans is groot dat het bij zakelijke abonnementen wel lukt, maar ik heb niet genoeg kennis over de zakelijke producten om daar zekerheid over te geven. Je kunt het natuurlijk altijd even navragen bij de collega's op het zakelijk forum.
@Raymondt
Dennis gaf je een antwoord op je specifieke vraag, het enige antwoord dat er mogelijk is. Of dat de beste oplossing overall is is niet gezegd, maar ook niet gevraagd.
En welke vraag is dat dan precies? Ik stelde helemaal geen directe vraag, Dennis mengde zich in de discussie en had dus ook gewoon even de context kunnen lezen.
De enige vraag die ik stelde was “Bedankt voor de link naar ARC. Zal daar eens wat over lezen, en ben ook wel benieuwd wat KPN hierover te zeggen heeft?”, en die was dus niet over een PTR maar in het algemeen over de deliverability.
Je blijft namelijk met een ip-adres verzenden die als 'residential ip' te boek staat. Dat kan invloed hebben. Op een thuisverbinding zit bij eventuele storingen geen SLA, zoals die er bijvoorbeeld op netwerken in datacentra wel is.
Dat is op eigen risico, ik vraag toch ook niet om een SLA? Overigens maken storingen niet heel veel uit op een mailserver omdat die het gewoon blijft proberen.
Tevens moet je voor een hoop zaken het wiel opnieuw uit gaan vinden (zoals bijvoorbeeld als het gaat om spamfiltering). Dat hoeft niet persé erg te zijn, omdat het bijvoorbeeld een hobby is, maar maakt dat het gelijk verstandig voor een goeie mailafhandeling?
Het is inderdaad een hobby, en ik snap niet helemaal wat dit ermee te maken heeft? Ik betaal toch voor mijn aansluiting, en dan mag ik daar toch binnen de mogelijkheden en wet mee doen wat ik wil? En of het verstandig is maak ik toch ook zelf wel uit? Of gaat KPN mij voorschrijven wat ik met mijn persoonlijke devices uitspook?
Zo zijn er nog tal van redenen op te noemen waarom het naast het PTR dingetje onverstandig is, of kan zijn.
Vertel?
Er is overigens geen enkele weerstand tegen een fatsoenlijk ingerichte mailserver.
Gelukkig.
Maar (er vanuitgaande dat je hier doelt op het mogelijk maken van het instellen van een PTR) er is vanuit het bedrijf wel een keus gemaakt dat dit een dienst is waar we niet in willen investeren om dit in stand te houden en te onderhouden.
Dat is en was mij al duidelijk voor ik dit topic begon. Zoals je je misschien nog wel kunt herinneren begon ik daar zelf mee in mijn persoonlijke bericht naar je. Nogmaals, ik vroeg hier niet naar.