On Tue, 2007-04-10 at 12:20 +0200, Magnus Holmgren wrote:
> SPF doesn't break forwarding if employed carefully. Mail isn't forwarded
> totally randomly; in sane configurations a user U tells a system A to forward
> his mail to system B. If B wants to enforce SPF, they have to allow U to tell
> them about this forwarding, so that an exception can be made. A relatively
> secure and not too user-unfriendly way of doing this could be by letting the
> user forward their mail to a special address on this form:
> user+forwarded-(secret)@domain.example, where (secret) is a sufficiently
> random string. Otherwise they could specify the IP addresses the forwarded
> mail can come from (but that's complicated), or in many cases simply
> specifying the mail address forwarded from, letting the SPF-enforcing server
> make educated guesses, can work.
And what happens then when the receiving MTA needs to send a
notification back to the sender?
One of the biggest complaints I hear about SPF is from travelling
people, who want to compose messages offline and send them the instant
they get an internet connection again, without having to jump through
VPN hoops. Like they always have done. If SPF changes that, then SPF
breaks that.
If it can't be made 100% transparent to the users (in both ends) without
the cooperation of /all/ servers involved, it's a bad idea. Backwards
compatible means compatible in all scenario, not 'if NNN does XXX'.
