Re: [dmarc-discuss] Beware of the size limit in DMARC URIs
Actually, from the code, I'm surprised we handle a single address with ! correctly. I'll file a bug. Brandon On Tue, Oct 4, 2016 at 12:21 AM, Juri Haberland via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > Hi, > > while writing a patch for OpenDMARC, I stumbled accross problems with the > size limit in DMARC URIs that some of the big players have. > > Microsoft cannot cope at all with an URI like "rep...@example.org!10m" - > you won't receive a single report. > > Yahoo and Google do send a report and respect the size limit - as long as > this URI is the only one in the rua tag. > As soon as one adds another URI (with or without size limit) to the rua > tag, Google and Yahoo forget to strip the size limit from the URI and thus > try to send a mail to "rep...@example.org!10m"! > > As OpenDMARC also had problems with the size limit in older versions, it is > best to avoid the use of size limits for now. > > > Juri > ___ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
[dmarc-discuss] Report sizes and transports, was Re: Beware of the size limit in DMARC URIs
On 10/13/16 10:53, John Levine wrote: > It's a poor idea to put stuff into a spec if nobody's planning to > implement it, because that generally results in a spec that doesn't > work when someone tries later. I take your point, but I understood anecdotally that the large end of the range of reports were getting big enough to cause concern to those handling them daily. I guess I'll have to wait for somebody with direct knowledge to speak up - it isn't something I'm seeing with my own domains/reports. So first up, backup the anecdotal suggestion that there's a need based on the observed growth of report sizes. Second, an expression of willingness to implement. > The original http language was > hopelessly broken, so I offered something different that I think > would have worked, but nobody ever tested. > > So if DMARC reports are getting too big, I'd be happy to resuscitate > the http language in a short draft to update RFC 7489, but only if > there are a few people who plan to implement each side of it so we can > be sure that it works. Sure, I didn't mean to suggest we'd reinsert something without discussion - let alone something that hadn't been tested/vetted properly. That's real, substantive work for the WG. --S. ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Beware of the size limit in DMARC URIs
Whoah there! This thread has been hijacked by the lack of reading comprehension. Nobody (in this thread) has complained of DMARC reports being too large. The problem in this thread is an issue with some DMARC report senders failing to parse the DMARC URIs properly, if that DMARC URI includes size limits. I now return you to our normally scheduled programming. Matt > On Oct 13, 2016, at 10:53 AM, John Levine via dmarc-discuss >wrote: > >> There's another question to raise in the IETF working group - do we need >> to re-consider the use of HTTPS as an alternative transport for reports? >> (Background: HTTP was in the original spec, but hadn't been implemented, >> and so was dropped several years ago.) >> >> If we're running into the common size limits on email messages for >> reports at the largest senders/receivers today, what should we be >> planning for in five years? In ten? Maybe it's time to re-establish an >> alternate channel in the spec, so it will be ready when we need it. > > It's a poor idea to put stuff into a spec if nobody's planning to > implement it, because that generally results in a spec that doesn't > work when someone tries later. The original http language was > hopelessly broken, so I offered something different that I think > would have worked, but nobody ever tested. > > So if DMARC reports are getting too big, I'd be happy to resuscitate > the http language in a short draft to update RFC 7489, but only if > there are a few people who plan to implement each side of it so we can > be sure that it works. > > Technically it's really simple, a single HTTP PUT operation which > is not as common as GET or POST, but should be supported by every > web server, and automagically provides for compression and duplicate > report elimination. > > R's, > John > > ___ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well terms > (http://www.dmarc.org/note_well.html) ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Beware of the size limit in DMARC URIs
>There's another question to raise in the IETF working group - do we need >to re-consider the use of HTTPS as an alternative transport for reports? >(Background: HTTP was in the original spec, but hadn't been implemented, >and so was dropped several years ago.) > >If we're running into the common size limits on email messages for >reports at the largest senders/receivers today, what should we be >planning for in five years? In ten? Maybe it's time to re-establish an >alternate channel in the spec, so it will be ready when we need it. It's a poor idea to put stuff into a spec if nobody's planning to implement it, because that generally results in a spec that doesn't work when someone tries later. The original http language was hopelessly broken, so I offered something different that I think would have worked, but nobody ever tested. So if DMARC reports are getting too big, I'd be happy to resuscitate the http language in a short draft to update RFC 7489, but only if there are a few people who plan to implement each side of it so we can be sure that it works. Technically it's really simple, a single HTTP PUT operation which is not as common as GET or POST, but should be supported by every web server, and automagically provides for compression and duplicate report elimination. R's, John ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Beware of the size limit in DMARC URIs
Sorry for not saying so earlier, but we're looking into the multiple to thing. We'll roll out a fix asap. On Thu, Oct 13, 2016 at 3:30 AM, Alessandro Vesely via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > On Wed 12/Oct/2016 21:38:45 +0200 Juri Haberland via dmarc-discuss wrote: > >> On 12.10.2016 12:17, Steven M Jones via dmarc-discuss wrote: >> >>> On 10/12/16 01:32, Juri Haberland via dmarc-discuss wrote: >>> >> >> Btw: Did anyone notice that AOL sends DMARC reports with two To: headers? >>> >>> Looking at the last few reports I received from them for this domain, I >>> only see one 5322.To header. But the most recent report was >>> mid-September. Anybody else out there seeing two? It could make tracking >>> down a bug much easier for them. >>> >> >> My last report is half a year old, but has two headers, too: >> >> From: abuse_dm...@abuse.aol.com >> To: r...@dmarc.sapienti-sat.org >> To: pboza...@ag.dmarcian.com >> >> So it seems, AOL is putting every rua URI into a seperate To: header... >> > > I'm surprised no AOL people spoke, so I CC this to the address I found in > their report_metadata/email field. > > Instead, we could add an extra_contact_info entry pointing to this list, > no? > > Ale > > ___ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Beware of the size limit in DMARC URIs
On Wed 12/Oct/2016 21:38:45 +0200 Juri Haberland via dmarc-discuss wrote: On 12.10.2016 12:17, Steven M Jones via dmarc-discuss wrote: On 10/12/16 01:32, Juri Haberland via dmarc-discuss wrote: Btw: Did anyone notice that AOL sends DMARC reports with two To: headers? Looking at the last few reports I received from them for this domain, I only see one 5322.To header. But the most recent report was mid-September. Anybody else out there seeing two? It could make tracking down a bug much easier for them. My last report is half a year old, but has two headers, too: From: abuse_dm...@abuse.aol.com To: r...@dmarc.sapienti-sat.org To: pboza...@ag.dmarcian.com So it seems, AOL is putting every rua URI into a seperate To: header... I'm surprised no AOL people spoke, so I CC this to the address I found in their report_metadata/email field. Instead, we could add an extra_contact_info entry pointing to this list, no? Ale ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)