I tried to lay out why I believe reports with server identity would be important to domain owners. In this context, verification reduces ambiguity about whether the HELO name accurately identifies the server organization. Reverse DNS can also be useful, but it may indicate the ISP rather than the server owner, so I started with just the HELO to reduce pushback.
Examples: if the example.com administrator sees a DMARC failure for a message from a *.edu server, he may presume that a mailing list forward is involved. If he sees the same thing from an Office365 server, he may presume a forwarding action after a spam filter that tagged "External sender". But if he sees unauthenticated messages from 10 different IPs tied to badguys.com, he can presume an attack on his domain identity. Thus last exampkeis more worrisome. To the non-DMARC portion of your question: Server identity and verification are grossly underused. If I determine that an IP is purely malicious, I could block on the IP address, but it is wiser to block on the server domain as well. I do not know all IP addresses used by the attacker, but I do know that it is a malicious server organization. On the flip side, verified server identity is the correct way to implement a local policy fix for SPF errors. The rule structure looks like this: If server domain is X, and server name is verified by fcDNS, and Mail from is Y, then treat same as SPF PASS. (Since the server domain name is part of the policy rule, and therefore not an ISP name, either HELO or RevDNS can be used for server domain.) Unfortunately commercial products do not understand sender authentication or have given up trying. I have confirmed a long list of products which cannot construct a rule like the one above. Most say that if SPF fails, simply ignore SPF and hope that domain is never impersonated. So they embrace impersonation rather than blocking it. Doug On Sun, Oct 23, 2022, 11:47 AM Murray S. Kucherawy <[email protected]> wrote: > Can you explain what this would provide? Section 4.1.4 of RFC 5321 says > of the EHLO parameter: > > An SMTP server MAY verify that the domain name argument in the EHLO > command actually corresponds to the IP address of the client. > However, if the verification fails, the server MUST NOT refuse to > accept a message on that basis. > > > Since it can't be used for filtering decisions, and thus in effect this > could be any value and the server MUST accept it, I've never understood why > it's an interesting thing to include in any sort of report or > decision-making. > > -MSK, participating > > On Thu, Oct 20, 2022 at 6:35 PM Douglas Foster < > [email protected]> wrote: > >> We are missing an opportunity if we do not include the HELO name along >> with the IP address in the aggregate reports. I would also recommend >> asking for fcDNS status (confirmed, not confirmed, not tested). >> >> The report receiver could do the fcDNS check himself, but there is a >> possibility that the results will be different if tested from a different >> geography at a later point in time. >> >> 1) HELO will often produce fcDNS confirmed, and it is often an accurate >> clue to the server owner even when it is not confirmed. Once you know the >> server owner, you can reliable correlations across all IPs used by that >> organization. >> >> 2) Despite what might be assumed, the HELO name does not change very >> often, even for spam sources. If and when the name does change, you still >> learn valuable data. Three possibilities come to mind: >> a) The IP ownership has changed so the IP reputation needs to be >> re-evaluated. >> b) The source is playing name games so the IP reputation should be >> mistrusted further. >> c) The source is behind a shared V6-to-V4 gateway, so reputation needs to >> be based entierely on HELO instead of IP.. >> >> And as a side benefit, we can ask for this information without causing >> any further disaggregation. >> >> Doug Foster >> >> >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
