Re: [Mailman-Users] New To Mailman
Anthony (N2KI) writes: That is what I am currently doing with IS Mail. In order for the messages to be sent, IS Mail logs into my account and then sends the mail. I believe the problem could be related but not limited to reverse DNS authentication. My Ip resolves to my domain name via DYNDNS. I also have an MX record as well as a TXT record that is set to allow my domain to send email through my ISP account. As with Mark and Carl, I think you are running into receiving domains that are willing to do things to reduce spam received at even fairly high cost in reliable delivery of desired mail. Specifically, they are rejecting or discarding mail that is not authenticated merely because of the lack of authentication. The basic configuration should have an MX record that points to a host with an A record (not a CNAME), and a PTR record that also points to the same name as the A record. It sounds like you have that at the ISP. Note that if your MX record points to the ISP, and all your mail in and out goes through the ISP, it probably doesn't much matter (for mail!) what your own host's DNS configuration is. Now, I'm not sure what you mean by a TXT record. Perhaps it's SPF, looking something like this: example.com. TXT v=spf1 +mx a:colo.example.com/28 -all (the v=spf1 is what makes it SPF). For more about SPF TXT records, see http://tools.ietf.org/html/rfc7208#section-3. (I don't recommend reading the whole thing, if you're not familiar with RFC-ese already.) If not, you should publish one. However, SPF only solves a minority of authentication problems. Also, your SPF record should specify your ISP's MX, as well as your own domain. You should also sign outgoing messages according to the DKIM protocol. This requires creating keypairs, and publishing them in the DNS. I'm not comfortable trying to explain how this is done in an email, though. You should ask your ISP if they do this/can do this for you. Finally, you should ensure that the DKIM-signed mail is never altered in any way once signed. If your ISP provides SPF for itself and DKIM-signs the mail for you, this condition is satisfied. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] Controlling Mailman 2.1.x remotely
Hello, Mailman experts. I've been doing some development work for a Tokyo-based NPO that offers participation in a number of Mailman lists as one of the benefits of membership in the organization. Because membership in the organization is a requirement for participating in the Mailman discussions, the organization has not been providing members with direct access to the Mailman administrative features for subscribing and unsubscribing, but instead has been providing a homegrown administrative interface that uses PHP and curl to simulate user interactions via POST. When a recent update to Mailman introduced CSRF tokens, however, this approach broke down and the organization has been struggling to figure out how to manage the lists ever since. We know that Mailman 3 provides an API, which is exactly what we need, but because the site and Mailman lists are both on shared hosting, we are currently only able to use Mailman 2.1.x. Can anyone recommend a good approach to managing subscriptions in an automated way using either PHP or Python until such time as we can get our host to upgrade to Mailman 3? Any suggestions or pointers would be greatly appreciated. With many thanks in advance, Sako Eaton -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Controlling Mailman 2.1.x remotely
On 08/10/2014 01:07 PM, S. Patrick Eaton wrote: ... has been providing a homegrown administrative interface that uses PHP and curl to simulate user interactions via POST. When a recent update to Mailman introduced CSRF tokens, however, this approach broke down and the organization has been struggling to figure out how to manage the lists ever since. If you are authenticating to the admin interface via a cookie from a preceding login, you can modify the PHP scripts to first GET the page, parse the page for the value of csrf_token and submit csrf_token=value along with the POST data. On the other hand, if you authenticate by including adminpw=adminpassword in the POST data, the CSRF token is not required as it is only checked if authentication is not via password. See http://wiki.list.org/x/Z4A9. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
