Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

2016-10-13 Thread Brandon Long via dmarc-discuss
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

2016-10-13 Thread Steven M Jones via dmarc-discuss
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

2016-10-13 Thread Matt Simerson via dmarc-discuss
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

2016-10-13 Thread John Levine via dmarc-discuss
>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

2016-10-13 Thread Paul Rock via dmarc-discuss
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

2016-10-13 Thread Alessandro Vesely via dmarc-discuss

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)