I don't see any action items here in terms of changes to the base draft. Am I correct in that assessment? I'll assume yes; someone should speak up if otherwise.
-MSK On Wed, Aug 14, 2013 at 8:32 PM, Steven M Jones <s...@crash.com> wrote: > Adding the [dmarc-ietf] list for spec considerations. Direct follow-up > spec discussion there; operational issues can remain with [dmarc-discuss]. > PLEASE edit your To: and Cc: accordingly. > > > Originating message on [dmarc-discuss] from Tomki Camp queried how many > implementations obeyed the optional report size limitations described in > section 5.1 ... > > > On 08/14/2013 05:21 PM, Franck Martin wrote: > >> On Aug 14, 2013, at 5:07 PM, Matt Simerson <m...@tnpi.net> wrote: >> >>> I just iterate over the URI list and send the report to each one, >>> skipping over any where the message size exceeds the published limit. >>> >> But this is not the intent, you are supposed to cut the report in smaller >> chunks and send them... (just saying ;) >> > > Can you cite the section(s) for that behavior, Franck? > > Matt, if no reports can be sent based on size limits, do you then send a > "reports too big" notice to all the mailto: URIs per section 11.2.4? > > > Section 11.2 indicates that any reporting URI with a size limit lower than > the current report size should be skipped, with an exception that if no > URIs qualify to receive a report, Mail Receivers should follow section > 11.2.4 to send a "report too big" notice. > > Section 11.2.1 for the Email transport notes the possibility of a report > larger than can be accepted by a mailto: URI and refers to section > 11.2.4. Section 11.2.2 for the HTTP transport does not make a specific > reference to the size limitation; neither does section 11.2.3 which notes > the opportunity to add additional transports in future. I'd recommend that > it just be made clear that the handling specified in section 11.2 applies > across all transports. > > > Pursuant to the original question though, has anybody received an error > report as described in section 11.2.4 in the wild? I'm curious because > there's a note in the spec that a more rigorous definition will be added > based on operational experience... I'll go bodge something to generate > some, but organic examples would probably be better if we've got any. > > Thanks, > --Steve. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
