The question here is not a technical one, but a marketing one.
The thousands of SPF records in DNS provided by admins represent an
asset that I would like to see used. To provide incentive to
grow that asset, we need to be crystal clear about how it is
useful. Any downside, or FUD is damaging.
SPF can be used to vet HELO/EHLO between MTAs. This is non-controversial,
and effective to prevent some kinds of spoofing. Checking SPF on
HELO/EHLO enables reputation checking of MTAs. This is all
goodness. No downside. No FUD.
I want to have this conversation - stand-alone. I want to . I want this
convince certain admins and authors to implement SPF checking
on HELO/EHLO. Without crystal clear guidance from SPF "authorities",
that's proven difficult.
The verbiage on the web site is helpful, but is not clear enough on
this single point to help me convince people that SPF can be used in
this way safely and effectively.
Most conversations I have about SPF get bogged down in forwarding tech
and FUD. My thrust - check HELO - quickly gets derailed, and I
don't get my HELO checking.
The tech talk about RFCs is certainly important, and efforts are
underway to do the heavy lifting to "fix forwarding", but I want
to separate the "clearly useful - let's just do it" part (HELO)
from the "arguably wonderful, but we can't quite get to closure" parts.
The former is easy, and I would like to see it emphasized. The latter
detracts from the former when its debate clouds the issue, and leaves
admins thinking that SPF is a "single package".
I think we can fix this by separating these two ideas.
-dgl-
On Wednesday 07 January 2009 07:38, Alessandro Vesely wrote:
Scott Kitterman wrote:
On Wed, 07 Jan 2009 12:22:24 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it>
wrote:
| the key difference between handling aliases (Section 3.9.1) and
| forwarding (this subsection) is the change to the backward-pointing
| address in this case.
The standard literally says that forwarding with a changed return
address is not forwarding. Should that be interpreted like the Baima
Lun saying that a white horse is not a horse?
With a mailing list, a message is sent to the list manager, it is
delivered, and then a new message (with a usually modified body) is
created and sent to the subscriber list.
Why a "new" message? The Message-ID field should be preserved. Even if
the ENVID value should be changed and (positive) DSNs should not reach
the original sender, I wouldn't decorate MTAs with the authorship that
creating a new message requires... Automated body modifications are
also done by clients and MSAs.
So whatever 'forwarding' is, it's pretty clearly not a mailing list.
It was John Klensin who used that term for the action discussed in the
"List" subsection of the standard.
For me, as an MTA admin, the distinction has always been that there's a
delivery. I've no idea how that relates to what's in the current standards
as it's been some time since I looked.
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com