Thread: Publish SPF records for postgresql.org?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any reason not to publish SPF records for postgresql.org? Do we have control over the TXT records, and does anyone know which servers are authorized to send mail for postgresql.org? How do we handle mail forwarding for those who own an @postgresql.org email address? - -- Jonathan Gardner jgardner@jonathangardner.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFARMFLqp6r/MVGlwwRAq6MAJ9Jqj1F+A/yE21Yh2jN3VCJQLVy9QCfcE9H je7UOKauptN/vTkcaW6HNAY= =DmIK -----END PGP SIGNATURE-----
On Tue, Mar 02, 2004 at 09:15:55 -0800, "Jonathan M. Gardner" <jgardner@jonathangardner.net> wrote: > > Is there any reason not to publish SPF records for postgresql.org? Do we > have control over the TXT records, and does anyone know which servers are > authorized to send mail for postgresql.org? How do we handle mail > forwarding for those who own an @postgresql.org email address? If you do this be sure to warn all of the list users, since this will break forwarding for people on the lists if the server they forward to checks SPF info.
On Tue, 2 Mar 2004, Jonathan M. Gardner wrote: > ------------------------------------------------------------------------------ > /usr/local/libexec/ppf_verify: pgp command failed > > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > gpg: Signature made Tue Mar 2 13:15:55 2004 AST using DSA key ID C546970C > gpg: Can't check signature: public key not found > ------------------------------------------------------------------------------ > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there any reason not to publish SPF records for postgresql.org? Do we > have control over the TXT records, and does anyone know which servers are > authorized to send mail for postgresql.org? How do we handle mail > forwarding for those who own an @postgresql.org email address? Until today, I didn't know what SPF records were ... We have control over everything, but as for sending mail 'for postgresql.org', there are *alot* of them, since we have several relay servers provided by various ppl around the world to spread the load of distribution for the mailing lists ... as to mail forwarding, each person has the ability to add a Sieve filter to forward as they desire, or read straight off the main server ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tuesday 02 March 2004 09:44 am, Bruno Wolff III wrote: > On Tue, Mar 02, 2004 at 09:15:55 -0800, > > "Jonathan M. Gardner" <jgardner@jonathangardner.net> wrote: > > Is there any reason not to publish SPF records for postgresql.org? Do > > we have control over the TXT records, and does anyone know which > > servers are authorized to send mail for postgresql.org? How do we > > handle mail forwarding for those who own an @postgresql.org email > > address? > > If you do this be sure to warn all of the list users, since this will > break forwarding for people on the lists if the server they forward to > checks SPF info. This is the line I am getting in my mail logs for SPF checking on the postgresql mailing list messages: Milter add: header: Received-SPF: none (dervish.jonathangardner.net: domain of pgsql-hackers-owner+m50598=jgardner=jonathangardner.net@postgresql.org does not designate permitted sender hosts): 1 Time(s) And, we will do not necessarily have to implement SPF on incoming mail. If we do decide to do that, then we can just add a header saying that the check failed, and forward the mail to the list anyway. Notice that SPF only checks the envelope MAIL FROM line, or as some people call it the SMTP from, not the header from. Modern mailing lists (like the one postgresql uses) rewrites that as it is now, so forwarding will not break with SPF. (Notice that it is comparing the IP address of the server I got mail from with the domain "postgresql.org". Since there are no SPF records for postgresql.org, it can't check yet.) Also, we may publish an SPF records that ends in "?all" initially, which will mean "if the email comes from anywhere else, pretend like we never even mentioned SPF". We then run some tests, identify servers we forgot about, and then change that to "~all", which means softfail, or in other words "If it comes from anywhere else, then it probable isn't valid, but it may be." When we finally identify all of the servers that are sending postgresql mail, and are absolutely sure, then and only then will we do "!all", declaring that we are absolutely sure no one else should be sending valid mail for postgresql.org. Hopefully, between the "?all" and "~all" steps we will have identified all of the postgresql mail servers, so that those who are implementing SPF on incoming mail will not have to endure having their postgresql mail sent to the junk folder. -- Jonathan Gardner jgardner@jonathangardner.net
On Tuesday 02 March 2004 09:53 am, Marc G. Fournier wrote: > On Tue, 2 Mar 2004, Jonathan M. Gardner wrote: > > Is there any reason not to publish SPF records for postgresql.org? Do > > we have control over the TXT records, and does anyone know which > > servers are authorized to send mail for postgresql.org? How do we > > handle mail forwarding for those who own an @postgresql.org email > > address? > > Until today, I didn't know what SPF records were ... > I was hoping to increase awareness of SPF with this email... I guess I have succeeded! ;-) http://spf.pobox.com/. I should've mentioned it earlier. > We have control over everything, but as for sending mail 'for > postgresql.org', there are *alot* of them, since we have several relay > servers provided by various ppl around the world to spread the load of > distribution for the mailing lists ... > We can add all of these servers to a domain like "mailrelay.postgresql.org", and then declare any server in "mailrelay.postgresql.org" as a valid server in the TXT record for postgresql.org. That way, we won't have to have a huge TXT record. My only concetion is when you (scrappy@postgresql) go to send mail as scrappy@postgresql.org, you are sending it through ganymede.hub.org. You'll need to either get this domain listed in the SPF record (see above), or start sending your email as scrappy@postgresql.org through a common server with SMTP authentication. The same applies for anyone else who has a postgresql.org email account. -- Jonathan Gardner jgardner@jonathangardner.net
On Tuesday 02 March 2004 09:44 am, Bruno Wolff III wrote: > On Tue, Mar 02, 2004 at 09:15:55 -0800, > "Jonathan M. Gardner" <jgardner@jonathangardner.net> wrote: > > Is there any reason not to publish SPF records for postgresql.org? Do > > we have control over the TXT records, and does anyone know which > > servers are authorized to send mail for postgresql.org? How do we > > handle mail forwarding for those who own an @postgresql.org email > > address? > > If you do this be sure to warn all of the list users, since this will > break forwarding for people on the lists if the server they forward to > checks SPF info. This is the line I am getting in my mail logs for SPF checking on the postgresql mailing list messages: Milter add: header: Received-SPF: none (dervish.jonathangardner.net: domain of pgsql-hackers-owner+m50598=jgardner=jonathangardner.net@postgresql.org does not designate permitted sender hosts): 1 Time(s) We have to keep two issues seperate: (1) Adding SPF records so others can check outgoing mail, and (2) Implementing SPF on incoming mail. We do not necessarily have to implement SPF on incoming mail. If we do decide to do that, then we can just add a header saying that the check failed, and forward the mail to the list anyway. Notice that SPF only checks the envelope MAIL FROM line, or as some people call it the SMTP from, not the header from. Modern mailing lists (like the one postgresql uses) rewrites that as it is now, so forwarding will not break with SPF. (Notice that it is comparing the IP address of the server I got mail from with the domain "postgresql.org". Since there are no SPF records for postgresql.org, it can't check yet.) Also, we may publish an SPF records that ends in "?all" initially, which will mean "if the email comes from anywhere else, pretend like we never even mentioned SPF". We then run some tests, identify servers we forgot about, and then change that to "~all", which means softfail, or in other words "If it comes from anywhere else, then it probable isn't valid, but it may be." When we finally identify all of the servers that are sending postgresql mail, and are absolutely sure, then and only then will we do "!all", declaring that we are absolutely sure no one else should be sending valid mail for postgresql.org. -- Jonathan Gardner jgardner@jonathangardner.net
On Tue, 2 Mar 2004, Jonathan Gardner wrote: > My only concetion is when you (scrappy@postgresql) go to send mail as > scrappy@postgresql.org, you are sending it through ganymede.hub.org. > You'll need to either get this domain listed in the SPF record (see > above), or start sending your email as scrappy@postgresql.org through a > common server with SMTP authentication. The same applies for anyone else > who has a postgresql.org email account. Okay, well, the thought was great, but this just kinda put the nail in the coffin, so to say :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tue, Mar 02, 2004 at 10:40:33 -0800, Jonathan Gardner <jgardner@jonathangardner.net> wrote: > Notice that SPF only checks the envelope MAIL FROM line, or as some people > call it the SMTP from, not the header from. Modern mailing lists (like the > one postgresql uses) rewrites that as it is now, so forwarding will not > break with SPF. (Notice that it is comparing the IP address of the server I > got mail from with the domain "postgresql.org". Since there are no SPF > records for postgresql.org, it can't check yet.) The case I am talking about is for a person that gets email from a postgres mailing list at server A and forwards it to server B. If server B checks SPF records it will reject this message because it is not coming from a server authorized to use postgresql.org as an envelope sender domain. This is something that probably won't affect many people, but it would still be nice to give people a heads up before turning it on. That way they can adjust things so the mail gets through. (By such methods as using SRS on server A or changing their subscription address to server B.)
On Tuesday 02 March 2004 12:58 pm, Bruno Wolff III wrote: > On Tue, Mar 02, 2004 at 10:40:33 -0800, > > Jonathan Gardner <jgardner@jonathangardner.net> wrote: > > Notice that SPF only checks the envelope MAIL FROM line, or as some > > people call it the SMTP from, not the header from. Modern mailing lists > > (like the one postgresql uses) rewrites that as it is now, so > > forwarding will not break with SPF. (Notice that it is comparing the IP > > address of the server I got mail from with the domain "postgresql.org". > > Since there are no SPF records for postgresql.org, it can't check yet.) > > The case I am talking about is for a person that gets email from a > postgres mailing list at server A and forwards it to server B. If server > B checks SPF records it will reject this message because it is not coming > from a server authorized to use postgresql.org as an envelope sender > domain. This is something that probably won't affect many people, but it > would still be nice to give people a heads up before turning it on. That > way they can adjust things so the mail gets through. (By such methods as > using SRS on server A or changing their subscription address to server > B.) 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. 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 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. -- Jonathan Gardner jgardner@jonathangardner.net
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.