On 10/04/07, Arthur Hagen <art-f@???> wrote: > 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.
Actually that's an unrealistic expectation - things do change. What it
does do though is put up a barrier to adoption, which a number
individuals/orgs will regard as a showstopper. That number should
reduce over time, though, if the benefits can be demonstrated.
>
> 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'.
Again, nice idea but is it realistic? People got over the idea that
they could use any old SMTP server as an open relay.
