>Yes, I'm advocating for simple in-band signalling as one of the >mechanisms that should probably be supported. This won't carry >very detailed information, but will be timely and will be seen by >the *actual* MX host that is misconfigured.
So long as we understand that you also need out-of-band reporting to catch MTAs that can't take the in-band reports, sure, and also for aggregate reports (see below.) >> have a different dedicated domain/outsourced recipient; potentially fails >> in the same way as the original message > >Right, and may cause a flood of notices to a single address, creating >congestion (processing and/or storage bottleneck). Naive designs >that "pipe" the notices to a script or append them to a mailbox >can easily fail to scale. This is pure FUD. Lots of people take similarly bursty DMARC reports and we don't have any trouble with them. On the other hand, a design so bad that it chokes trying to process a lot of SMTP reports coming in at once is equally likely to choke on a lot of in-band reports. >> con: doesn't provide aggregation, in-band means if the MX is really >> misconfigured or the sender never talks to the right MX there's no way to >> get reports across > >The assumption is that the MX host in question will report the >alerts to the administrator, performing reasonable aggregation when >alerts arrive quickly. Um, no. A quick review of the draft will remind us that that there are aggregate reports and there are failure reports, and they're different. My DMARC failure report parser sticks the info into a a database as the reports arrive. What you do with the reports is definitely out of scope here. >Definitely not mutually exclusive. The case I'm trying to make is >that the initial operational priority is timely notification of >misconfiguration (expired, untrusted or wrong name certs). I'd really like to hear from people who plan to implement this at scale rather than guessing what they will find important. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
