On Tue, Mar 02, 2004 at 13:31:35 -0800,
Jonathan Gardner <jgardner@jonathangardner.net> wrote:
>
> You are correct. However, this only affects the user if the have enabled SPF
> on server A and if they haven't enabled SRS on server B. If they are going
> to enable SPF on server A, then they should understand the ramifications of
> doing so. Every domain that publishes SPF will break their configuration,
> not just postgresql.org.
Unfortunately the user may not have much control over either server A or
server B or know whether or not they are using SRS or SPF. That is part
why I think notifying all of the lists about this when you are going to
deploy it is a good idea.
> I think if you compare the cost to benefit of publishing or not publishing
> SPF records, it is apparent that publishing SPF records is the wise thing
> to do. We would only be declaring to the world that email coming from
Actually I don't. I think breaking forwarding is not worth the trade off.
SRS has several problems and there it isn't a good fix for the problems
caused by SPF.
> certain server is totally valid, while other servers are unknown (?all),
> probably not valid (~all) or not valid at all (!all). What the recipients
> of email do with this information is their responsibility. If they want to
> make it so that SPF-enabled email doesn't go through, that's their
> business. If they want to be silly and implement SPF in a way that will
> break forwarding, that's their call.
Just remember that the mailing list members aren't necessarily the ones
maintaining their mail servers and that postgresql.org publishing SPF
records might cause problems for some of them that they aren't going
to understand. The symptom on their end is going to be that they stop
getting email from the lists. Their first thought isn't likely to be,
I bet that the postgres people started publishing SPF records and I had
better check with the adminstrators for my email providers to see how
they are handling SPF and SRS.