On Sun, 2004-12-05 at 15:36, Frank Ellermann wrote:
I really hate it when "they" say that "SPF breaks forwarding"
without mentioning that this is its one and only feature, and
that it's kind of obvious that testing MTA IPs announced by a
sender works only at the border of the receiver, not later.
I too. Recently in this thread, Alex van den Bogaerdt wrote:
The comment was: "forwarder is sender"
You reply: "he didn't write it"
In other words, you think the author is the sender. This is a wrong
perception.
Authors write, senders send.
And yes, this is important. The forwarding machine may be allowed to send
a message authored by me, it may not pretend to >be me< while sending.
The forwarding entity is responsible for the message and should receive
the bounce, not the author of the message.
And I totally agree with this. I also agree with David Woodhouse in
<1101947190(_dot_)4642(_dot_)9(_dot_)camel(_at_)localhost(_dot_)localdomain>,
where he said:
I fully support the practice of rejecting mail from domains
publishing '-all' records with a 551 error code if you would
otherwise have to forward it.
But unfortunately, this "fixes" forwarding in an SPF-enforcing-world by
getting rid of forwarding, and I don't think the SPF position on
forwarding should be "don't do it".
David Woodhouse went on with:
That's much better than SRS.
Except that it's not if anyone values forwarding actually working.
But I also recognize (although do not agree with) the different
perspective that Nico Kadel-Garcia expressed.
As such, I've been looking for methods of doing forwarding in an
SPF-enforcing-world that SPF can support.
Apparently we have to offer more strategies, incomplete list:
- global white list trusted-forwarder.org (temporary)
- local white lists
- some kind of SRS
- some kind of SUBMIT (with corresponding 2822 headers)
- some kind of digest (or single message/rfc822) forwarding
- ordinary POP3 (incl. all solutions working on top of POP3)
I still like ODMR/ATRN, a lot, if it could be done a per-user basis
rather than per-domain. It would be similar to POP3 solutions, I
suppose, except for having to maintain local mailboxes to be POP'ed to.
POP3 and related solutions are an option, but it's a lot more work and
continued maintenance than plain re-injecting the mail into the Internet
(people would end up becoming Email Service Providers rather than just
deploying a forward file for the sake of convenience -- I'll set up a
simple forward for an ex-employee (if company policy allows it), but I'm
not interested in keeping that user's mailbox around and having to
maintain quota control and whatnot for 'em after the leave the company).
RSR, er, Reverse Source Routes, as I've already outlined
OTOH it's not our job to explain all details. Bye, Frank
I agree. But everything I've looked at has, in my opinion, come down to
being either more work, offer fewer advantages, and/or requires parties
other than just the forwarder to do something than the forwarder using
SRS. I was hoping that by discussing some of the alternatives in depth,
some of the detractors would come out and say "oh, that's a good idea"
or might see that SRS isn't actually all that bad compared to the
alternatives.
Obviously something needs to be done about forwarding -- I am far from
the first one to say that! Unfortunately, many of the detractors of SRS
would rather say "I don't like it, I won't deploy it in my forwarding
setups" or "SPF breaks forwarding, thus SPF is bad" rather than actually
recognizing that there is an issue that requires solutions. Everytime I
come across another way to "solve the forwarding problem", and then
compare it to SRS, SRS wins everytime because it is the simplest
solution and requires the least number of people to change.
I thought this thread was on-topic
It is, and in fact it helped me to find out that Meng's idea
of local white list does not cover all cases where SRS isn't
good enough (or where a forwarder simply hates the SRS idea)
Your "big ISP" example was convincing, they cannot offer a WL
for their customers, because SPF tests based on the RCPT TO
are a technical nightmare (probably impossible).
Heh, success! :)
I vaguely remember someone had generated a matrix of forwarding
solutions so they could be easily compared. Unless I'm mis-remembering,
I can't seem to find this now.
Andy.