On Fri, 2004-11-26 at 09:16 +0000, Chris Haynes wrote:
Let me focus on the heart of the debate, and I'm doing my best to be fair to
both sides here, and to use neutral language.
I think this is very useful; thanks. But I think you've slightly
misrepresented the 'conservative' position.
Still in the spirit of 'neutral language' , let me use the terms
'conservative'
and 'progressive' for the two positions I am aware of.
The conservatives look at the above example and say
"SPF is breaking the mail system. Forwarding has worked perfectly well in the
past; it is SPF which is changing; it is SPF which is wrong. SPF should not
be
deployed".
That's not quite how I'd phrase it. I'd say it was more like this:
"SPF is breaking the mail system for no good reason. Forwarding has
worked perfectly well in the past; it is SPF which is changing; it is
SPF which is wrong. SPF should not be deployed because there are better
ways of achieving the same thing, without the need for such changes."
Now, continuing in my attempt to be fair, let me withdraw any implication that
the conservatives are against any change whatsoever. I'm using 'progressive'
and 'conservative' purely in the context of this one topic.
Indeed. If a change is absolutely necessary to make progress, I don't
think many people would be arguing against it. See the fairly widespread
support for closing open relays, for example. The problem in this
particular case is that the 'progressives' are trying to enforce change
while the 'conservatives' see ways that the same goals can be achieved
without it.
In particular, it's much easier to justify changes which can be limited
to participating endpoints, rather than changes which affect
uninterested third parties who may encounter the mail in transit.
How, and from where, would one get an 'authoritative' ruling about the
conformance or non-conformance of forwarding (using the origin's MAIL FROM
with
a new RCPT TO) to the extant SMTP architecture?
Actually, I don't think we need such an answer. We know the extent of
existing practice; what was intended in 1982 isn't really relevant any
more.
The important question, in my mind, is 'Do we _need_ to change it?'. And
unless all the alternative schemes like CSV/DK/SES are shown to be
unworkable, I cannot really see how anyone could answer 'yes' to that
question.
Meng Weng Wong has previously said, "When banks start DomainKeys or
S/MIME signing all outbound mail, I promise to give up SPF and Sender
ID".¹ I'll follow that with my own promise:
When everyone has given up on DomainKeys, IIM, SES, CSV, BATV and the
similar proposals which don't need to change the world, I promise to
publish an SPF record and make my forwarding hosts cope with the new
requirements of SPF.
--
dwmw2
¹ http://www.imc.org/ietf-mxcomp/mail-archive/msg04998.html