On Tue 07/Apr/2020 09:09:01 +0200 Damian Lukowski wrote:
>>>> Authentication-Results: domain.tld, spf=pass [email protected]
>>>
>>> Needs to be removed? I say no.
>>
>>
>> Yes, and log it.
>
> Please notice the comma instead of the semicolon, it wasn't a typo.
> Would you still remove it?
If I can lazily (or sloppily) identify it as an authserv-id, so can do other
tools too.
>> Both cases are renamed to Old-Authentication-Results anyway. The part that
>> would log it, however, doesn't recognize the quotes (I'm going to fix it now)
>> and intermittently removes the header.
>
> I wanted to object that the RFC does not allow to tamper with "innocent"
> headers, but it actually does not forbid it. That said, I could even
> remove previous A-R headers altogether and be RFC compliant, so a lazy
> evaluation parser can be compliant as well.
IMHO that's the simplest approach. By renaming (otherwise obscuring) instead
of deleting you still leave room for debugging and forensics.
>> Note2: even if a tool accepted a list of trusted authserv-id's, consider a
>> MUA
>> simultaneously accessing two mailboxes, at example.com and example.org, say.
>> Of course you would configure the tool to trust both of their authserv-id
>> (which is already beyond what an average user is willing to configure).
>> Then,
>> a malicious party can send you a message at your @example.com address,
>> bearing
>> a faked Authentication-Results by example.org. Should the tool trust it?
>
> Wouldn't a trust-list per mailbox solve the issue, instead of a global
> trust-list?
Per-mailbox lists might seem to do it. However, consider, in the above
scenario, making the decision to forward some or all of your @example.org
traffic to your example.com mailbox, directly from example.org server. Now
you'd want to trust example.org A-Rs even when they arrive through example.com.
The only easy way that I see to accomplish that is to instruct example.com to
whitelist example.org's A-R; if example.com admins trust example.org, that is:
For simplicity and maximum security, a border MTA could remove all
instances of this header field on mail crossing into its trust
boundary. However, this may conflict with the desire to access
authentication results performed by trusted external service
providers. [...] A more robust border
MTA could allow a specific list of authenticating MTAs whose
information is to be admitted, removing the header field originating
from all others.
https://tools.ietf.org/html/rfc8601#section-5
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
