On Tue, 2004-11-23 at 14:06 +0000, Mark wrote:
Actually a lot of people do the A->B->C->D thing. The host 'B' may
be one of many hosts on which a user has a mail account such as
kernel.org, ftp.uk.linux.org, etc. The 'C' could be my infradead.org
account; a permanent address. And 'D' may be wherever I actually want
my mail to end up this week.
If C is your own host, David, then you cannot use the argument that you
have no control over it. :) Unless you purposely want to break things,
going from C -> D.
Personally, I have control over it. I, personally, _could_ make it do
SRS, if 'D' is checking SPF and refuses to stop checking SPF when I tell
them, as their customer, that it's throwing away my valid mail. But I'd
be more likely just to go to a different ISP.
But that isn't really the point. Lots of people do this because it's the
simplest way to do it. You forward all the random accounts all over the
place to one permanent address, then forward _that_ address to wherever
you want your mail to go at the time. Not _everyone_ controls any
machine in the sequence like I do; few do in fact.
Terry Fielder wrote:
Since you control the forwarding of B, just forward it to D directly
bypassing C.
Which was my point. Regardless of SPF/SRS, common, practical sense
dictates that you never forward over more hops than is stricty necessary;
because each extra hop presents a new location where something could go
wrong, transmission-wise.
If kernel.org forwards mail for David, and David has control over where
that .forward goes (and it would be silly to argue that he had not), then
he would forward to D directly. And if he must per se forward to his own
host, C, first, then surely, at his own host, he can make that forward
work.
The subset of users who are also sysadmins is not large, and neither is
it interesting.
I am saying these things just to inject a bit of sanity in the ongoing
forwarding saga. Like I said on IRC, yesterday, some people have their own
agenda. Like showing SPF/SRS is bad, at all cost, so as to promote their
own version of SES. Which is fine, because we live in a free world. And
sometimes I even go along, for the sake of argument. And sometimes
I do not. :)
An amusing assertion. I actually joined the SPF list in the first place
because I'd heard of it and was planning to implement it. After a brief
glance at what it actually did, I realised it was too broken for me to
deploy it. I've been stating that fact since _long_ before I had the
idea for which Meng Weng Wong coined the term 'SES'.
I don't really know what 'my version' of SES would be. The one
documented at http://ses.codeshare.ca/ doesn't bear my name at the
moment, and has a few details I'm not entirely sure I agree with,
although that's the one that seems to have developed from my original
idea voiced on this list early in the year, and it's a whole lot better
than SPF is. Certainly BATV can't be considered 'my version of SES'
either. But any of them solve the same problems that SPF _tries_ to
solve, just without the breakage that SPF introduces. So whatever
version of SES you think is mine, yeah by all means use that.
Actually I'm as much in favour of DK and IIM -- although I'm holding off
on implementing those till the STRIVERS working group concludes with a
merger of the ideas therein. But they complement each other.
Mostly though, I think SPF is actively detrimental. There are people out
there who are only going to try one of the many schemes available to
them, and if it's SPF and they have to stop because they're losing (or
rejecting) valid mail, they may not actually try one of the nonbroken
schemes.
It's not about what you do instead -- although certainly there are
viable alternatives and I'm not just suggesting that you should do
_nothing_. It's about not doing something stupid.
--
dwmw2