Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 12:16:36 -0700

Hello,

Issue #12 has been open for some time.  Please review the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html and 
Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue.

Regards,
S. Moonesamy

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 22 Aug 2012 21:18:18 -0400

> Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on this issue.
Using <> to forward emails is a bad idea.  Empty mail from is reserved 
for error/status returns.  In fact, many MTAs use a VERP like scheme to 
reject <> for emails they did not send.

-1 for using <> as a solution to the mis-configured user of forwarding 
services problem

BTW, section 9.2.2 part 2 does not mention one effective scheme: the 
forwarder simply rejects the email with 552 status (redirect IIRC) and 
the target email.  And for that matter, if the target email simply 
rejects an email that fails SPF due to a forwarder, the sender has the 
target email in the bounce.  Using that info is not as easy to automate 
as with 552, but a somewhat savy end-user could do so manually.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 00:11:14 -0400

> as with 552, but a somewhat savy end-user could do so manually.

Good point.  I had forgotten about that one.  Added.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Thu, 23 Aug 2012 05:52:12 +0000

+1

I don't like forwarding looking like bounces or worst bounces looking like
forwarding. It really mess up figuring out what email you just received.
If I don't know what it is, it is likely ending up not being processed
correctly, creating issues for the sender and/or receiver.

On 8/22/12 6:18 PM, "Stuart Gathman" <[email-masked]> wrote:

>_______________________________________________
>spfbis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spfbis

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 Aug 2012 11:26:55 +0200

On Thu 23/Aug/2012 03:18:18 +0200 Stuart Gathman wrote:
>> http://www.ietf.org/mail-archive/web/spfbis/current/msg00374.html
>> and Section 9 of the draft-ietf-spfbis-4408bis-05 and comment on
>> this issue.

> for error/status returns.

It is DSNs which are bound to have an empty mfrom, not the other way
around.

> In fact, many MTAs use a VERP like scheme to reject <> for emails
> they did not send.

They should be listed, according to
http://www.rfc-ignorant.org/policy-dsn.php

> -1 for using <> as a solution to the mis-configured user of forwarding

Hm... it's not much the user who is responsible of the
misconfiguration, as the forwarder itself.  The point you make below
is correct, but still far from providing an effective solution for
forwarders who don't want to rewrite the MailFrom  (see last paragraph
of http://tools.ietf.org/html/rfc5598#section-5.1 ).

> target email in the bounce.  Using that info is not as easy to
> automate as with 552, but a somewhat savy end-user could do so manually.

For a similar point, in part 1, bullet #1 we could exemplify

   "v=spf1 mx ?exists:%{ir}.list.dnswl.org -all"

instead of or in addition to the spamhaus example.  IME that's quite
effective as it solved all the practical cases I knew of, and still
allows -all.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 03:00:45 -0700

Hi Alessandro,
>They should be listed, according to
  [URL removed]

I don't think it would be a good idea to have a discussion about the 
above on the SPFBIS mailing list.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 08:56:38 -0700

Hi Alessandro,
>effective as it solved all the practical cases I knew of, and still

I believe that it is better if the SPFBIS WG is vendor-neutral.  If 
we exemplify the above text it won't be flagged by ID-nits.  I will 
notice it during my review.  I will have to choose whether to look 
the other way.  Other reviewers will also face the same choice.

There has been ample discussion about Issue #12 on this mailing 
list.  I'll leave it to you (or any other WG participant) to propose 
an alternative.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 Aug 2012 18:59:00 +0200

On Thu 23/Aug/2012 17:56:38 +0200 S Moonesamy wrote:
> I believe that it is better if the SPFBIS WG is vendor-neutral.  If we
> exemplify the above text it won't be flagged by ID-nits.  I will
> notice it during my review.  I will have to choose whether to look the
> other way.  Other reviewers will also face the same choice.

I agree completely with your vendor-neutral feeling.  However, the
effectiveness of mentioning an actual whitelist cannot be achieved
with circumlocutions.  It is already unlikely to convince (i) ADMDs to
put that term before -all, and (ii) non-rewriting alias expanders to
subscribe to the whitelist appearing in the SPF record of the site
that rejects their mail, even if we mention which list we're talking
about...

Dnswl.org is not commercial, much like the currently exemplified
spamhaus.org.  Subscriptions and small-volume querying are free.
Ietf.org is itself subscribed: http://www.dnswl.org/s?s=ietf.org

> There has been ample discussion about Issue #12 on this mailing list. 
> I'll leave it to you (or any other WG participant) to propose an
> alternative.

An alternative is http://www.spamhauswhitelist.com/.  Is that better?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Aug 2012 11:05:28 -0700

On Thu, Aug 23, 2012 at 8:56 AM, S Moonesamy <[email-masked]> wrote:
> exemplify the above text it won't be flagged by ID-nits.  I will notice it
> during my review.  I will have to choose whether to look the other way.
> Other reviewers will also face the same choice.
>
> There has been ample discussion about Issue #12 on this mailing list.  I'll
> leave it to you (or any other WG participant) to propose an alternative.

I agree.  I'm also concerned with a tendency to include an example of
every possible use of SPF to solve some problem.  It feels like it's
getting mighty cluttered.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 11:24:29 -0700

>Ietf.org is itself subscribed: http://www.dnswl.org/s?s=ietf.org

It would be inappropriate of me to favor X over Y.  Whether X is free 
is immaterial.

>An alternative is http://www.spamhauswhitelist.com/.  Is that better?

No.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Aug 2012 17:42:45 -0400

<OT>
You looking to open for a major can of worms? :)

This sort of thing has long been a major taboo, even for technology 
that is donated by a market/technology leader to the public domain.

It is actually a "black art" to be able to design/write functional and 
technical specification that is general and fair to all involved. 
Takes lots of engineering time to do be able to do this. For the IETF, 
many have long, especially those like myself who put engineering trust 
in their peers, looked at the IETF as the gatekeeper and to watch for 
these sort of things.

That said, we do look at market leaders to lead the way - but with 
fair and open new directions that doesn't add a strategic barrier and 
dependency to your own growth (this is where anti-trust seeds are laid).
</OT>

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 17:41:36 -0000

>An alternative is http://www.spamhauswhitelist.com/.  Is that better?

Hi.  I run the Spamhaus Whitelist and I would strongly object if this
document mentioned it or any other specific DNSWL or DNSBL.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Aug 2012 12:54:21 -0700

Hello,

I would like to thank Alessandro Vesely for suggesting alternatives 
to address Issue #12.  There has been significant discussion about 
this issue.  Murray Kucherawy commented [1] on the tendency to 
include an example of every possible use of SPF to solve some 
problem.  Stuart Gathman mentioned [2] that using <> to forward 
emails is a bad idea.  John Levine objected [3] to the draft 
mentioning specific DNSWL or DNSBL.

I read the messages which have been posted since Issue #12 was opened 
for discussion.  It is my understanding that some of the discussion 
[4] is about an effective solution for forwarders who don't want to 
rewrite the MailFrom.  The WG Chair previously stated that the issue 
is deployment advice.  I don't see any convergence of views on what 
advice to provide.  I will close the ticket for Issue #12.

Regards,
S. Moonesamy
SPFBIS WG co-chair

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02281.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02245.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02265.html

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:41:23 -0400

On Thursday, August 23, 2012 11:05:28 AM Murray S. Kucherawy wrote:
> > I'll

My recollection is that we're collecting things in section 9 and will later 
decide if it should all stay in 4408bis are be in another document.  My intent 
is to add a vendor neutral variant of this to section 9 and then we can 
revisit what, if anything, should come out later.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:51:51 -0400

On Sunday, August 26, 2012 01:41:23 AM Scott Kitterman wrote:
> decide if it should all stay in 4408bis are be in another document.  My
> intent is to add a vendor neutral variant of this to section 9 and then we
> can revisit what, if anything, should come out later.

When I looked over section 9, this is very similar, but a much better example 
than the existing first item for the originating ADMD in 9.2.2, so I updated 
that to reflect this approach.  It ended up shorter.

Scott K