Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt

From: [email-masked]
Date: Tue, 24 Jan 2012 07:32:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : SPF Authentication Failure Reporting using the Abuse Report Format
	Author(s)       : Scott Kitterman
	Filename        : draft-ietf-marf-spf-reporting-03.txt
	Pages           : 15
	Date            : 2012-01-24

   This memo presents extensions to the Abuse Reporting Format (ARF),
   and Sender Policy Framework (SPF) specifications to allow for
   detailed reporting of message authentication failures in an on-demand
   fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-03.txt

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 10:36:27 -0500

On Tuesday, January 24, 2012 07:32:17 AM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 
> 	Title           : SPF Authentication Failure Reporting using the Abuse
> Report Format Author(s)       : Scott Kitterman

Changes from the last version:

* Updated the r= definition to only use localparts and append the SPF domain.
* Removed the rf= (report format) modifier as there's only ARF.
* Changed ri= (report interval) to rp= (report percentage) to match DKIM draft
   (and list discussion).
* Added Neutral to the requested report types for completeness.
* Deleted Reports From Unrelated Domains security consideration since it's
   resolved by the changes in this revision.
* Added Forgeries and Automatic Generation to security considerations based on
   the text in the DKIM draft.
* Updated IANA registry request, examples, and front matter for these changes.
* Other minor updates

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 10:39:16 -0500

On Tuesday, January 24, 2012 10:36:27 AM Scott Kitterman wrote:
> * Changed ri= (report interval) to rp= (report percentage) to match DKIM
> draft (and list discussion).
> * Added Forgeries and Automatic Generation to security considerations based
> on the text in the DKIM draft.

Also reworked the envelope sender selection discussion based on John Levine's 
feedback ...

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2012 21:28:49 -0000

Nits: in Sec 3, the description of r= still refers to rf=.

In 6.3, how come it says that a bounce address MUST pass SPF but a
HELO only SHOULD pass?  (I'm not necessarily arguing, I'm asking.)

Other than that, looks fine.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 17:02:01 -0500

> Nits: in Sec 3, the description of r= still refers to rf=.

Thanks.  Fixed locally.

> Other than that, looks fine.

Sending the report from an address the passes SPF, modulo bugs and DNS errors, 
solves the potential looping problem. If you're using NULL Mail From and the 
only identity you have for an SPF check is EHLO/HELO then there's still no 
loop problem, although you might generate an extra report if there's a 
rejection due to EHLO/HELO not passing SPF.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 10:53:41 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, January 24, 2012 2:02 PM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt
> 
> Sending the report from an address the passes SPF, modulo bugs and DNS
> errors, solves the potential looping problem. If you're using NULL Mail
> From and the only identity you have for an SPF check is EHLO/HELO then
> there's still no loop problem, although you might generate an extra
> report if there's a rejection due to EHLO/HELO not passing SPF.

The text in -03 says:

"Per Section 2 of [DSN], the NULL envelope sender address of the report MAY be chosen to ensure that no delivery status reports will be issued in response to the report itself."

That's not consistent with Section 2 of [DSN], which says SHOULD and MUST.  We should either drop the reference, or be consistent with it.  If we drop it, we need to be prepared to explain why we're contradicting [DSN], which is a draft standard.

Also:

1) 6.3 has a missing "<" before an xref, so the XML is revealed in the produced document.

2) I've changed "r=" to "ra=" so that all of the reporting tags are distinguishable as "r[a-z]".  Seem reasonable for yours as well?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 14:56:12 -0500

On Wednesday, January 25, 2012 10:53:41 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Tuesday, January 24, 2012 2:02 PM
> > To: [email-masked]
> "Per Section 2 of [DSN], the NULL envelope sender address of the report MAY
> be chosen to ensure that no delivery status reports will be issued in
> response to the report itself."
> 
> That's not consistent with Section 2 of [DSN], which says SHOULD and MUST. 
> We should either drop the reference, or be consistent with it.  If we drop
> it, we need to be prepared to explain why we're contradicting [DSN], which
> is a draft standard.

This isn't actually a DSN (is it)?  Perhaps "Similar to Section 2 of [DSN} 
..." instead of "Per Section 2 of [DSN] ..."?
 
> 1) 6.3 has a missing "<" before an xref, so the XML is revealed in the

Fixed locally.  Thanks.

> 2) I've changed "r=" to "ra=" so that all of the reporting tags are
> distinguishable as "r[a-z]".  Seem reasonable for yours as well?

Sure.  Done locally.  I notice in your draft you use two styles for the ABNF 
specification:

rep-ra-tag = %x72.61
spf-rp-tag = %x72 %x69

The SPF draft uses the latter format.  Is one of these preferred?  I suspect 
it would be better to pick one form and stick with it over using two (I'm not 
an ABNF expert at all, so please advise).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 11:59:46 -0800

> Sent: Wednesday, January 25, 2012 11:56 AM
> To: [email-masked]
> This isn't actually a DSN (is it)?  Perhaps "Similar to Section 2 of
> [DSN} ..." instead of "Per Section 2 of [DSN] ..."?

It's not a DSN proper, right, but we still want to avoid the same situations that DSN has to avoid.

> The SPF draft uses the latter format.  Is one of these preferred?  I
> suspect it would be better to pick one form and stick with it over
> using two (I'm not an ABNF expert at all, so please advise).

I'll switch it to the first.  I tried to get them all but I must've missed some.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 15:14:06 -0500

On Wednesday, January 25, 2012 11:59:46 AM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, January 25, 2012 11:56 AM
> > To: [email-masked]

OK.  I changed it to "Similar to ..."

> > Sure.  Done locally.  I notice in your draft you use two styles for the
> > ABNF specification:
> > 
> > rep-ra-tag = %x72.61
> > spf-rp-tag = %x72 %x69
> > 

OK.  I switched the SPF draft to the first one as well.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 12:19:02 -0800

> Sent: Wednesday, January 25, 2012 12:14 PM
> To: [email-masked]

It seems to me that we should say the same thing here.

Here's what my working copy has:

6.2.  Envelope Sender Selection

   In the case of transmitted reports in the form of a new message
   (versus rejections during an [SMTP] session), it is necessary to
   construct the message so as to avoid amplification attacks,
   deliberate or otherwise.  The envelope sender address of the report
   needs to be chosen so that these reports will not generate mail
   loops.

   Per Section 2 of [DSN], the envelope sender address of the report
   SHOULD be chosen to ensure that no delivery status reports will be
   issued in response to the report itself, and MUST be chosen so that
   the report will not cause a mail loop.

   Therefore, if an [SMTP] transaction is used to send a report, the
   MAIL FROM command MUST either use the NULL return address, i.e.,
   "MAIL FROM:<>", or one that will pass [SPF] MAIL FROM checks on
   receipt.  The HELO/EHLO command SHOULD also be selected so that it
   wil pass [SPF] HELO checks.

Does that fit with what you and John were saying?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 15:41:39 -0500

On Wednesday, January 25, 2012 12:19:02 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, January 25, 2012 12:14 PM
> > To: [email-masked]

Speaking for myself, I think so.  It still has the Per section 2 of [DSN] 
problem.  How about this (a hybrid of what you have here and what I've got 
locally):

   In the case of transmitted reports in the form of a new message
   (versus rejections during an [SMTP] session), it is necessary to
   construct the message so as to avoid amplification attacks,
   deliberate or otherwise.  The envelope sender address of the
   report MUST be chosen so that these reports will not generate mail
   loops.  

   Similar to Section 2 of [DSN], the envelope sender address of the
   report SHOULD be chosen to ensure that no feed back reports will be
   issued in response to the report itself.

   When an [SMTP] transaction is used to send a report, the
   MAIL FROM command MUST either use the NULL return address, i.e.,
   "MAIL FROM:<>", or one that will pass [SPF] MAIL FROM checks on
   receipt.  The HELO/EHLO command SHOULD also be selected so that it
   will pass [SPF] HELO checks.

Scott K

---

From: Derek Diget <[email-masked]>
Date: Wed, 25 Jan 2012 17:12:56 -0500 (EST)

On Jan 24, 2012 at 10:36 -0500, Scott Kitterman wrote:
=>* Updated the r= definition to only use localparts and append the SPF domain.

How will this work for sites that publish "null" SPF records 
(<http://www.openspf.net/FAQ/Common_mistakes#all-domains>)?

By publishing a "null" SPF record the domain part is not suppose to be 
used for email.  But if the site wanted to get reports for attempts to 
use that domain, how would they?  Sending to 
<localpart-addr>@<non-mail-domain> won't work.

Similar issue with "HELO" SPF records 
(<http://www.openspf.net/FAQ/Common_mistakes#helo>).

For example with the following DNS/SPF records:
(I hope I don't have any errors below. :)

  example.com		TXT	"v=spf1 ip4:192.168.1.25 ip4:192.168.1.81 -all r=postmaster"
  			MX	10	mail.example.com

  mail.example.com	A	192.168.1.25
			TXT	"v=spf1 -a -all r=postmaster"
			
  www.example.com	A	192.168.1.80
			TXT	"v=spf1 -all r=postmaster"

  websrv1.example.com	A	192.168.1.81
			TXT	"v=spf1 -a -all r=postmaster"

Example 1:  A message is sent from mail.example.com's IP address.

  (connection source IP is from 192.168.1.25)
  HELO mail.example.com			--> SPF HELO check = Pass
  MAIL FROM:<[email-masked]>	--> SPF MAIL FROM check = Pass

No report generated.

Example 2:  A message sent from their web server.  (www.example.com IP 
is a virtual interface on the "websrv1" box.)

  (connection source IP is from 192.168.1.81)
  HELO websrv1.example.com		--> SPF HELO check = Pass
  MAIL FROM:<[email-masked]>	--> SPF MAIL FROM check = Pass

No report generated.

Example 3:  A message sent from a system not authorized

  (connection source IP is from 172.16.1.100)
  HELO mail.example.com			--> SPF HELO check = Fail

A report should be created (if I understand the concept of this draft) 
with r=postmaster for the mail.example.com SPF record being sent to 
<[email-masked]>.  But mail.example.com is not used as a 
domain for mail delivery.  No MX record, but in this case the A record 
is listening on port 25 is not configured to accept mail for messages 
addressed to @mail.example.com.

Example 4:  A message sent from a system not authorized

  (connection source IP is from 172.16.1.100)
  HELO dsl-100.1.16.172.big-isp.example.net	--> no SPF published = Pass
  MAIL FROM:<[email-masked]>		--> SPF MAIL FROM check = Fail

As with example 3, sending a report to <[email-masked]> 
won't work.  No MX record and the A record is not even listening on port 
25.

Does the last two example makes sense or am I missing something?

== 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 17:17:08 -0500

> <localpart-addr>@<non-mail-domain> won't work.

You are confusing sending and receiving.  Nothing says such domains don't 
receive mail.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 14:44:32 -0800

> Sent: Wednesday, January 25, 2012 12:42 PM
> To: [email-masked]
> Speaking for myself, I think so.  It still has the Per section 2 of
> [DSN] problem.  How about this (a hybrid of what you have here and what I've got
> locally):
>[...]

Works for me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 18:32:53 -0500

>> [DSN] problem.  How about this (a hybrid of what you have here and

Great. 

It occurs to me that maybe the [DSN] reference could be informative now. Once I'm in front of my computer again I'll look at it and check if that's the only place it comes up.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 15:34:41 -0800

> Sent: Wednesday, January 25, 2012 3:33 PM
> To: [email-masked]
> It occurs to me that maybe the [DSN] reference could be informative
> now. Once I'm in front of my computer again I'll look at it and check
> if that's the only place it comes up.

It is so in dkim-reporting already.

---

From: Derek Diget <[email-masked]>
Date: Wed, 25 Jan 2012 18:54:44 -0500 (EST)

On Jan 25, 2012 at 17:17 -0500, Scott Kitterman wrote:
=>On Wednesday, January 25, 2012 05:12:56 PM Derek Diget wrote:
=>> On Jan 24, 2012 at 10:36 -0500, Scott Kitterman wrote:
=>> =>* Updated the r= definition to only use localparts and append the SPF
=>> domain.
=>> 
=>> How will this work for sites that publish "null" SPF records
=>> (<http://www.openspf.net/FAQ/Common_mistakes#all-domains>)?
=>> 
=>> By publishing a "null" SPF record the domain part is not suppose to be
=>> used for email.  But if the site wanted to get reports for attempts to
=>> use that domain, how would they?  Sending to
=>> <localpart-addr>@<non-mail-domain> won't work.
=>
=>You are confusing sending and receiving.  Nothing says such domains don't 
=>receive mail.

Ok, I might have misspoken when I wrote "the domain part is not suppose 
to be used for email."

The FAQ says "Publishing "v=spf1 -all" says that a domain sends no 
mail."  Ok, got the "sending" part.  So, no legitimate mail is sent 
using that domain.

How does the domain owner receive reports of others trying to use the 
domain to send mail?  If the domain owner has said via the SPF record 
that the domain doesn't send mail, I would be highly surprised if the 
domain owner has configured anything to accept mail at that domain.

They are publishing the SPF record so that if somebody else wanted to 
send mail using that domain, it would receive a SPF fail versus getting 
the SPF none result if they didn't have the record.

Again if a domain owner publishes a SPF record of

  www.example.com		"v=spf1 -all -r=postmaster"

How do they get reports of sending (forgery) attempts using MAIL 
FROM:<[email-masked]> sent to them?

Do they have to put a MX record on www.example.com and configure their 
mail server to accept mail for that domain?  (I sure hope not.)

--

---

From: "John Levine" <[email-masked]>
Date: 26 Jan 2012 00:06:51 -0000

>domain owner has configured anything to accept mail at that domain.

If he wants to get the reports, he'd better.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Jan 2012 16:08:35 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, January 25, 2012 4:07 PM
> To: [email-masked]
> Subject: Re: [marf] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-03.txt}
> 

Do we need to call out this (somewhat obvious) situation in the draft?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 19:26:46 -0500

On Wednesday, January 25, 2012 03:34:41 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, January 25, 2012 3:33 PM
> > To: [email-masked]

It turns out it is in spf-reporting already as well.  

I've updated my local copy with the new language.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Jan 2012 19:28:32 -0500

On Wednesday, January 25, 2012 04:08:35 PM Murray S. Kucherawy wrote:
> > John Levine Sent: Wednesday, January 25, 2012 4:07 PM
> > To: [email-masked]
> > Subject: Re: [marf] r= using localpart - WAS: {Re: I-D Action:
> > draft-ietf-marf-spf-reporting-03.txt}> 

I hope we don't need to say that if you ask for reports you aren't going to 
get them unless you configure your system to accept them.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 28 Jan 2012 13:09:40 +0100

> get them unless you configure your system to accept them.

Derek's concern seems legitimate to me.  Although John's note may seem
obvious, let me recall that SPF is rather weak at checking helo names
because of a very similar reason.  We are demanding too much diligence
from domain admins, for a task they can achieve more easily by tracing
an included exists mechanism.

On the other hand, dkim-reporting has an rd= tag that makes such
flexibility possible.  What is the use case where rd= is different
than d=?  Why cannot we have the following for spf-reporting?

www.example.com          TXT "v=spf1 redirect=nomail._spf.example.com"
nomail._spf.example.com  TXT "v=spf1 -all rd=example.org"

_report._spf.example.org TXT "ra=spf-failures"

(The fixed prefix "_report._spf" and the missing v= are not very
SPFish, but may look simpler and consistent with dkim-reporting.)

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 28 Jan 2012 10:21:26 -0500

On Saturday, January 28, 2012 01:09:40 PM Alessandro Vesely wrote:
> > I hope we don't need to say that if you ask for reports you aren't going
> > to get them unless you configure your system to accept them.
> 

Why is SPF 'weak' at checking HELO names?  I think I misunderstand something 
about the premise of your statement.

What diligence are we asking for that is too much?

> than d=?  Why cannot we have the following for spf-reporting?

I missed that we still had that in the DKIM draft and I've sent a note 
regarding changing that as well.  I think it's better to keep the reports 
being sent back to the relevant domain (SPF domain as defined in check_host() 
or d= domain for DKIM) and let them make arrangements to relay them elsewhere 
if needed than to allow these messages to be sent to arbitrary domains that 
may not be expecting them.

Here's the security consideration we retired when we changed it to work the 
way it is now:

"6.2.  Reports From Unrelated Domains

   SPF records can be used by other domains via include mechanisms and
   redirect modifiers.  If reporting addresses included in these records
   are specified with a full addr-spec then reports for other,
   potentially unrelated, domains may be reported to this address.  In
   theory, malicious senders might use this as a path for generating
   large numbers of feedback reports.  To mitigate this issue, specify
   reporting addresses with a local-part so that reports will be
   directed to the original domain from which the message causing the
   feedback report was sent."

I think this was a good change and the DKIM draft should be changed similarly.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 29 Jan 2012 14:56:21 +0100

On 28/Jan/12 16:21, Scott Kitterman wrote:
>>>>>> How does the domain owner receive reports of others
>>>>>> trying to use the domain to send mail?  If the domain
>>>>>> owner has said via the SPF record that the domain doesn't
>>>>>> send mail, I would be highly surprised if the domain
>>>>>> owner has configured anything to accept mail at that 
>>>>>> domain.
>>>>> 

I just notice that admins don't bother publishing a record for each
and every host that mails out, although they publish one for the domain.

> What diligence are we asking for that is too much?

They should additionally publish an MX, for the sole purpose of
collecting failure reports.  We could as well ask to deliver them via
pony express.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 12:47:54 -0500

On Sunday, January 29, 2012 02:56:21 PM Alessandro Vesely wrote:
> >>> I hope we don't need to say that if you ask for reports you aren't
> >>> going to get them unless you configure your system to accept them.
> >> 
> > Why is SPF 'weak' at checking HELO names?  I think I misunderstand
> > something about the premise of your statement.
> 

I agree it's less deployed, but I wouldn't call that weak.

> collecting failure reports.  We could as well ask to deliver them via

An A record is sufficient.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 19:04:31 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, January 28, 2012 4:10 AM
> To: [email-masked]
> Subject: Re: [marf] r= using localpart
> 
> flexibility possible.  What is the use case where rd= is different than
> d=?

If some intermediary is doing your DKIM work for you, you might want that intermediary to receive failure reports as well.  But, then again, you could just as easily alias the failure address from your domain to them; this introduces a hop through your own mail servers, but it actually closes a security issue in that domain X can't fake a signature from domain Y on mail to domain Z and request reports go back to X, thus revealing whether or not Z is doing DKIM verification (if it participates in the reporting).

So maybe the "rd" for DKIM should just become "r=" which, if present and containing any value (as with "t=y"), then do the rest of the protocol using only the signing domain as the possible destination of reports.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 23:27:30 -0500

On Sunday, January 29, 2012 07:04:31 PM Murray S. Kucherawy wrote:
> > Alessandro Vesely Sent: Saturday, January 28, 2012 4:10 AM
> > To: [email-masked]
> If some intermediary is doing your DKIM work for you, you might want that
> intermediary to receive failure reports as well.  But, then again, you
> could just as easily alias the failure address from your domain to them;
> this introduces a hop through your own mail servers, but it actually closes
> a security issue in that domain X can't fake a signature from domain Y on
> mail to domain Z and request reports go back to X, thus revealing whether
> or not Z is doing DKIM verification (if it participates in the reporting).
> 
> So maybe the "rd" for DKIM should just become "r=" which, if present and
> containing any value (as with "t=y"), then do the rest of the protocol
> using only the signing domain as the possible destination of reports.

I think the key is that the information about where reports need to go needs 
to be found in DNS, not in the message, so if one takes the signing domain and 
looks up the record there, it will give you the localpart to go with that 
domain.  The r= flag you propose would (AIUI) be the trigger to do the DNS 
lookup to see if there's a DNS record asking for reports.

Is along the lines of what you intend?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 29 Jan 2012 20:42:18 -0800

> Sent: Sunday, January 29, 2012 8:28 PM
> To: [email-masked]
> I think the key is that the information about where reports need to go
> needs to be found in DNS, not in the message, so if one takes the
> signing domain and looks up the record there, it will give you the
> localpart to go with that domain.  The r= flag you propose would (AIUI)
> be the trigger to do the DNS lookup to see if there's a DNS record
> asking for reports.
> 

Specifically in the signer's DNS, but yes, that's right.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Jan 2012 23:59:47 -0500

On Sunday, January 29, 2012 08:42:18 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Sunday, January 29, 2012 8:28 PM
> > To: [email-masked]

Sounds good.  Thanks,

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 30 Jan 2012 10:07:11 +0100

On 30/Jan/12 05:59, Scott Kitterman wrote:
>>> From: ietf.org On Behalf Of Scott Kitterman
>>

+1: doing so is more consistent with the generic idea that "domain
claims some responsibility", and with the indication given in marf-as.

However, flag-triggered lookups leave report requests to the signer's
mercies.  If this message had a forged ietf.org's signature, there is
no way they can say they'd like to know about it.  Perhaps, it's fair
to say the verifier MAY lookup the _report RR anyway --which it would
tend to do if it remembers r= from signatures it saw earlier.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Jan 2012 09:25:44 -0800

> Sent: Monday, January 30, 2012 1:07 AM
> To: [email-masked]

Don't the ADSP reporting extensions cover this case?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 30 Jan 2012 20:04:24 +0100

On 30/Jan/12 18:25, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
> 

Yes, but only for the author's domain.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Jan 2012 11:12:06 -0800

> Sent: Monday, January 30, 2012 11:04 AM
> To: [email-masked]

I don't think I object to identifying the use case, adding that MAY, and then pointing out that it causes additional DNS load.

Others?