cadsite schreef: 1 week geleden
Het binnenkrijgen valt op te lossen door een forward op die adressen te zetten, verzenden zal dus in de webclient van mijn host moeten gebeuren.
Opgepast daarmee, ik heb daar al meer dan een jaar miserie mee.
Mailadressen die server-side forwarding doen naar een andere mailbox op een andere mailserver, en de security checks (SPF) falen voor een aantal verzenders (vooral grote namen als gmail, hotmail, etc).
Beste dat ik kan terugvinden is dat server-side forwarding de authentication breekt omdat mailserver 2 ziet dat mailserver 1 een mail stuurt in naam van domein X maar in de DNS van domein X staat mailserver 1 uiteraard niet gewhitelist in de SPF.
Is een gekend probleem / sideeffect van de nieuwere beveiligingstechnieken voor email, wanneer je server-side forward (en dus het FROM adres behouden blijft).
Een alternatieve tag (ARC) zou dat moeten oplossen, maar mailprovider 1 wil dat niet toepassen en provider 2 doet ambetant over dat whitelisten op hun mailserver. Resultaat: al meer dan een jaar onbereikbaar voor mensen met een mailadres van bepaalde providers.
Korte samenvatting van het issue bij server side forwarding:
Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.
DMARC allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes - such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer, and the SPF check will either fail (if the forwarder didn't change the bounce address) or be aligned with the mailing list domain and not with the message author's domain (unless the mailing list rewrites the From: header field.)
ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email. Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.
