Alex, I was referring to the discussion,which you apparently missed, not the prior draft. HELO and Reverse DNS names should be requested in our report format, along with the Source IP. They can (must) be optional for upward compatibility.
The reasons for including HELO and RevDNS are so obvious to me that I am surprised it was omitted by RFC 7489. If a report row requires corrective action, it needs to be resolved to a responsible organization and a responsible server. Source IP alone gives you neither. ReverseDNS is a starting point, but it can either represent the ISP client or the ISP itself, depending on SWIP status. Even if you get an organization from that, it only tells you the server when there is one-to-one NAT or no NAT. That leaves a lot of problems: 1) A machine is sending unauthorized messages, possibly because it is infected. Source IP tells you the firewall NAT address that is allowing the traffic out, not the infected machine. HELO will tell you the specific machine(s) that are involved. 2) A group of machines are used for sending legitimate messages on a send-only basis using a shared IP. One of the machines has a configuration error and is not applying DKIM signatures correctly. Source IP reporting tells you that you have a problem because less than 100% of messages from the IP are signed. HELO tells you which machine has the signature problem. 3) You want to know if an unexpected IP address represents a forwarder or an unauthorized message originator. The HELO and ReverseDNS together give you a high confidence about which domain represents the sender. Then you check your outbound message history to see if you are sending messages to that domain. If not, the server is probably a message originator. If yes, the server is probably a forwarder. The conclusion is tentative and ambiguous, but it gets you started. 4) Some HELO and ReverseDNS names provide a clue that the server is malicious. For example, an IP address in brackets is an allowed format for HELO, and it is in use on actual mail, but in my experience this always indicates that the server is a spam source. 5) Both HELO and ReverseDNS can be checked for validity by checking to see if the names can be resolved back to the Source IP address. In most cases, one or both will validate and indicate the server owner. Validation status can provide a clue about whether the server is legitimate or not. 6) Since DNS results can change with time and geography, it seems better to ask the reporting system to supply the Reverse DNS name, rather than waiting until the report is received by the domain owner. I am assuming that most report senders will capture HELO and ReverseDNS as part of their evaluation process, so I see it as a very reasonable data request with very little incremental cost to the evaluator. But for those who see it as a problem, the data is optional. When HELO is multi-valued because multiple machines are behind a single IP address, some disaggregation will occur. This strikes me as a benefit, not a disadvantage. Doug Foster On Wed, Jan 4, 2023 at 6:49 PM Brotman, Alex <[email protected]> wrote: > Which section are you referring to? Can you show where this has changed > from -06 (or RFC7489)? > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* dmarc <[email protected]> *On Behalf Of * Douglas Foster > *Sent:* Wednesday, January 4, 2023 6:35 AM > *To:* IETF DMARC WG <[email protected]> > *Subject:* [dmarc-ietf] Aggregate Reporting draft 7 - Server identity > > > > The new draft only asks for IP address, not HELO or Reverse DNS name. > HELO is valuable forensic information that cannot be obtained any other > way. Server identity becomes particularly important when the MailFrom > identity fails SPF or matches the RFC5322.>From domain. Why was these > fields omitted? > > > > Doug Foster > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
