> Terry: Would it be helpful at all for a large operator to get signal that this > small operator will be easily overwhelmed, or does it really make a > difference? I don’t think it would make a difference, although it’s hard to say. We’ve had problems delivering DMARC reports to DMARC aggregators before; the queues build up on our side and generate alerts. We try hard to deliver every email, but in this case we would delete the email and not retry.
Delivery problems are nothing new, we have to deal with them all the time. What we likely wouldn’t do is respect the fi= tag the way it’s written in the spec. From: Murray S. Kucherawy [mailto:superu...@gmail.com] Sent: Thursday, November 24, 2016 12:40 PM To: Terry Zink <tz...@exchange.microsoft.com> Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag +1 to Terry's points. On the other hand, "fi" is described mainly as a request (modulo the SHOULD NOT, which is debatable in my opinion) which means DMARC verifiers are free to ignore it. On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink <tz...@exchange.microsoft.com<mailto:tz...@exchange.microsoft.com>> wrote: Why would a large email receiver build out its infrastructure this way to support DMARC, when the DMARC-requester could build out *their* email infrastructure to support bursts of email, which they need anyway per my first point? Terry: Would it be helpful at all for a large operator to get signal that this small operator will be easily overwhelmed, or does it really make a difference? Marco: I don't agree with the use of ARF's "Incidents" count in this way, because that field is intended to indicate the number of identical incidents that were aggregated into a single report. If you want to use that mechanism, it should be clear that only identical attack incidents should be reported that way. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
