Subject: Re: [marf] VERP in marf-as (fwd)

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2012 09:35:49 -0500

> Ideas?

VERP is a swell technique, but this is an applicability statement, not a mail 
programming tutorial.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Feb 2012 18:24:14 +0100

On 06/Feb/12 15:35, John R Levine wrote:
>> Ideas?
> 
> VERP is a swell technique, but this is an applicability statement, not
> a mail programming tutorial.

Yes, we can just describe the purpose.  E.g., somewhere in Section 6:

   In the case of reports transmitted automatically, the envelope
   sender address MAY/SHOULD/MUST be set so that all error messages
   generated by the final deliveries will be returned to the
   transmitting entity.  Transmission of further reports to a failed
   address MAY be regulated taking into account previous experience
   of sending the same kind of report to the same address.  For
   example, if the address was used successfully in the past and
   retrieved from the DNS, transmission may be paused so as to give
   the relevant cached RR a chance to expire.

   In any case, reports transmitted automatically are an email
   service in the sense of RFC 3834, and those recommendations apply.

Do we want to say something like this?

---

From: "John R Levine" <[email-masked]>
Date: 6 Feb 2012 12:43:42 -0500

> Do we want to say something like this?

No.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 09:52:09 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
> Sent: Monday, February 06, 2012 9:44 AM
> To: Alessandro Vesely
> Cc: ARF mailing list
> Subject: Re: [marf] VERP in marf-as
> 

I agree.  See my previous desire to avoid turning this into an ARF cookbook.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 07 Feb 2012 12:21:20 +0100

On 06/Feb/12 18:52, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of John R Levine
>> 

Oh well, be that as it may.

RFC 3834's role, however, has to be stated, lest opposing
interpretations pop out the same question over and over.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 09:25:16 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alessandro Vesely
> Sent: Tuesday, February 07, 2012 3:21 AM
> To: [email-masked]

I don't agree.  RFC3834 appears to be about how to write auto-responders like vacation services.  In fact Section 3.2.1 suggests that there are cases where not using it is the right thing to do (DSNs, for example), and I think ARF is one of those cases.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 07 Feb 2012 19:35:22 +0100

On 07/Feb/12 18:25, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
> RFC3834 appears to be about how to write auto-responders like
> vacation services.  In fact Section 3.2.1 suggests that there are
> cases where not using it is the right thing to do (DSNs, for
> example), and I think ARF is one of those cases.

I think we ought to write that on the spec, otherwise it will be
debatable forever.

  Report generators are not automatic responders in the sense of
  Section 3.2.1 of [RFC3834]

would work for me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 11:24:20 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, February 07, 2012 10:35 AM
> To: [email-masked]
> Subject: [marf] Automatic Responses, was VERP
> 
> > RFC3834 appears to be about how to write auto-responders like vacation
> > services.  In fact Section 3.2.1 suggests that there are cases where
> > not using it is the right thing to do (DSNs, for example), and I think
> > ARF is one of those cases.
> 

Does anyone else think this is necessary?  I don't think RFC3834 covers what we're doing here at all, so I don't think we need to be concerned about possible debate on the topic.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 08 Feb 2012 00:33:13 +0100

> Does anyone else think this is necessary?  I don't think RFC3834 covers what we're doing here at all, so I don't think we need to be concerned about possible debate on the topic.

Hmm. RFC3834 identifies three classes of responders, among which Group 
Responders:

>     -  "Group Responders" exist to make automatic responses on behalf of
>        any of a significant set of recipient addresses (say, every
>        recipient in a particular DNS domain), in advance of, or in lieu
>        of, a response from the actual recipient.  Group Responders are
>        similar to Personal Responders except that in the case of a Group
>        Responder the criteria for responding are not set on a per-
>        recipient basis.  A "virus scanner" program that filtered all mail
>        sent to any recipient on a particular server, and sent responses
>        when a message was rejected or delivered in an altered form, might
>        be an example of a Group Responder.

This sounds a bit like the type of feedback we're talking about in the 
context of ARF (and DMARC for example). And as some of the topics, 
discussed in RFC3834, might be discussed also for ARF (loop prevention 
etc.) I'm not sure RFC3834 can completely be ignored.

If however we all agree that RFC3834 has no relationship to ARF, then 
let's explicitly mention this, as Alessandro proposed.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 15:31:24 -0800

Hi Rolf,

ARFs are not typically sent in place of delivery of a message, such as is the case when a virus scanner rejects a message.  ARF is normally generated in response to a user action post-delivery.

For the case of DKIM and SPF reports, rejection on failure is actually improper most of the time (the exceptions being ADSP and SPF "-all", both of which are currently discouraged).

What I'm trying to avoid is accumulating a list of informative references describing what ARF is not.  It seems to me that it's far less confusing for unfamiliar readers just to say what ARF is, and stop.

That said, if there's consensus to include it, we can add it.

-MSK

From: Rolf E. Sonneveld [mailto:[email-masked]]
Sent: Tuesday, February 07, 2012 3:33 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [marf] Automatic Responses, was VERP

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alessandro Vesely

To: [email-masked]<mailto:[email-masked]>

debatable forever.

would work for me.

Hmm. RFC3834 identifies three classes of responders, among which Group Responders:

This sounds a bit like the type of feedback we're talking about in the context of ARF (and DMARC for example). And as some of the topics, discussed in RFC3834, might be discussed also for ARF (loop prevention etc.) I'm not sure RFC3834 can completely be ignored.

If however we all agree that RFC3834 has no relationship to ARF, then let's explicitly mention this, as Alessandro proposed.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2012 01:36:54 -0000

>Does anyone else think this is necessary?

No.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 08 Feb 2012 10:55:17 +0100

Hi, Murray,

On 2/8/12 12:31 AM, Murray S. Kucherawy wrote:
>
> Hi Rolf,
>
> ARFs are not typically sent in place of delivery of a message, such as 
> is the case when a virus scanner rejects a message.  ARF is normally 
> generated in response to a user action post-delivery.
>
> For the case of DKIM and SPF reports, rejection on failure is actually 
> improper most of the time (the exceptions being ADSP and SPF "-all", 
> both of which are currently discouraged).
>

I know at least one bank which uses SPF -all for a domain that reflects 
one of their (old/obsoleted) brand names. Furthermore I can imagine that 
banks will register SPF -all for lookalide domains, if they own the 
domainname. Similarly with ADSP and DMARC we can expect organizations 
that will use the 'reject' option to indicate they never send mail with 
domain example.com.

> What I'm trying to avoid is accumulating a list of informative 
> references describing what ARF is not.  It seems to me that it's far 
> less confusing for unfamiliar readers just to say what ARF is, and stop.
>

I understand, just leave it out.

/rolf