FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ



 
 
LinkBack Thread Tools
 
Old 01-20-2009, 05:49 AM
Aaron Griffin
 
Default mailman hiccup

Broke and fixed and broke and fixed mailman tonight. Ignore the goofed
commits emails you may have gotten.

For documentation purposes, here's what happend:

* A few days ago we added a redirect from archlinux.org to
www.archlinux.org to address some silly caching issues.
* This broke mailman's web interface as it was using "archlinux.org"
and the redirect was blowing things up (silently)
* Used bin/withlist -r fix_url to modify the url for all the lists.
This also changed the list's host_name to the same URL. Whoops
* Readjusted all the host_name properties to archlinux.org so that the
mails work again.

Mailman hater for life,
Aaron
 
Old 01-20-2009, 06:31 AM
Geoffroy Carrier
 
Default mailman hiccup

On Tue, Jan 20, 2009 at 06:49, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> Mailman hater for life,
> Aaron

Whoever proposes a simple mailing list manager:
- Simple postfix integration (no -request, -unsubscribe, etc.: one
line in aliases)
- So E-mail confirmation through a web link
- Simple web interface (PHP or WSGI)
- Some sort of SQL for storage
- Multiple hostnames support (or better, no real care for hostnames
except distinction of MLs)
will get my unconditional love!

I don't care much about archive either.

How hard would that really be?

--
Geoffroy Carrier
 
Old 01-20-2009, 08:10 AM
RedShift
 
Default mailman hiccup

Geoffroy Carrier wrote:

On Tue, Jan 20, 2009 at 06:49, Aaron Griffin <aaronmgriffin@gmail.com> wrote:

Mailman hater for life,
Aaron


Whoever proposes a simple mailing list manager:
- Simple postfix integration (no -request, -unsubscribe, etc.: one
line in aliases)
- So E-mail confirmation through a web link
- Simple web interface (PHP or WSGI)
- Some sort of SQL for storage
- Multiple hostnames support (or better, no real care for hostnames
except distinction of MLs)
will get my unconditional love!

I don't care much about archive either.

How hard would that really be?



I've been working on my own mailing list manager, it's completely written in PHP and uses SQL as a backend, but at this point a bit specific to our setup. Because our company is all about open source I intend on releasing it as such. It's in need of an overhaul anyway, I'll get hacking at it again ASAP.

Glenn
 
Old 01-20-2009, 09:47 AM
Thomas Bächler
 
Default mailman hiccup

Aaron Griffin schrieb:

Broke and fixed and broke and fixed mailman tonight. Ignore the goofed
commits emails you may have gotten.

For documentation purposes, here's what happend:

* A few days ago we added a redirect from archlinux.org to
www.archlinux.org to address some silly caching issues.


Out of curiosity: Why? I hate that every site has to have "www" in front
of it, it's silly. Why don't we just have a redirect from
www.archlinux.org to archlinux.org?
 
Old 01-20-2009, 12:04 PM
Geoffroy Carrier
 
Default mailman hiccup

On Tue, Jan 20, 2009 at 10:47, Thomas Bächler <thomas@archlinux.org> wrote:
> Out of curiosity: Why? I hate that every site has to have "www" in front of
> it, it's silly. Why don't we just have a redirect from www.archlinux.org to
> archlinux.org?

Those statements might be obvious to you, but I hope some might learn
something, and I'll be able to refer to it in the future
---

Because www designates the *word wide* web, i.e. website available
from everywhere and for everyone.
It can be seen as a part of the whole company "network" designated by
the domain name.
Their internal tools (webmail, specific webapps, etc. but also
Jabber/SQL/etc. servers), which are only available from inside their
building network, or only usable by their members/other tools, are
other subparts available through their own sub.domain
This tradition predates the availability of the SRV records (for the
same domain name, how a specific service can be joined; still generaly
unimplemented), so the distinction:
1 - of different servers for different protocols
2 - of different services based on the same protocol (http being the
best example)
requires different subdomain...

It seems nice to use the (short) domain name for the prevalent
service, so it points to the website too.

Using a redirection permits to keep unique URIs for each resource and
gives better positions in search engines.

E-mail is an exception thanks to the MX records.

Traditions last! Finally the message I wrote for you: public resource
<-> URI with www...

--
Geoffroy Carrier
 
Old 01-20-2009, 04:16 PM
Aaron Griffin
 
Default mailman hiccup

On Tue, Jan 20, 2009 at 3:47 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Aaron Griffin schrieb:
>>
>> Broke and fixed and broke and fixed mailman tonight. Ignore the goofed
>> commits emails you may have gotten.
>>
>> For documentation purposes, here's what happend:
>>
>> * A few days ago we added a redirect from archlinux.org to
>> www.archlinux.org to address some silly caching issues.
>
> Out of curiosity: Why? I hate that every site has to have "www" in front of
> it, it's silly. Why don't we just have a redirect from www.archlinux.org to
> archlinux.org?

I'm on your side here, but in all honesty, it's arbitrary. More people
on the bug report were for www than not, and Dan got to it first.

Why I hate "www":
* world wide web... who says that anymore?
* For every other service, people are totally fine with using the
domain name and letting it decide what to do: ssh archlinux.org NOT
ssh ssh.archlinux.org; mailto aaron@archlinux.org NOT mailto
aaron@email.archlinux.org; ping archlinux.org NOT ping
icmp.archlinux.org; I can go on and on and on.

The only benefit I've heard here is relating to using a CNAME for the
website DNS, allowing us to redirect web traffic easier, for downtime
and the like, but that seems minor, and we can always change an A
record too. /me shrugs
 
Old 03-03-2009, 07:39 PM
RedShift
 
Default mailman hiccup

Geoffroy Carrier wrote:

On Tue, Jan 20, 2009 at 09:10, RedShift <redshift@pandora.be> wrote:

I've been working on my own mailing list manager, it's completely written in
PHP and uses SQL as a backend, but at this point a bit specific to our
setup. Because our company is all about open source I intend on releasing it
as such. It's in need of an overhaul anyway, I'll get hacking at it again
ASAP.


I'd love to be an early adopter

Plus I'd be happy to contribute...





Ok so here's what I've got so far:


When I was designing my anti-SPAM filter, I noticed you're just running a series of code after each other. To keep everything nice and tidy I split up the various routines into small pieces of code designed to do one thing and then pass on to the next filter. My project has the codename "redsky". Yes, it's cliché but I couldn't think of anything else.

By itself, redsky is pretty useless. It's only capable of running a series of filters after each other. The real power is in the filters itself. The 3 filters that come shipped with redsky are designed to interface with another piece of software called proxsmtpd (but can be used in other ways as well, they just use STDIN and STDOUT), but there's no reasons you could write your own input/output filters and make redsky a mini-SMTP server.


Here are the packages that are of interest:

* phpemailtoolbox (http://aur.archlinux.org/packages.php?ID=22237)

This is a small set of email related functions and classes. It is required by redsky.

* redsky (http://aur.archlinux.org/packages.php?ID=22261)

This is the main redsky code. It contains three filters:
* redsky_read: this reads the email in question from STDIN. It is designed for interfacing with proxsmtpd, but can be used in a generic manner as well.
* redsky_discard: when the discard flag is set on an email, this filter will log this event.
* redsky_out: this outputs the email to STDOUT, again designed to interface with proxsmtpd but is suitable for general purpose as well. In the mailinglist

* redsky-filters (http://aur.archlinux.org/packages.php?ID=24393)

This is a set of complementary filters for redsky, it has for example SMTP blacklist checking, whitelisting, autoreplies, etc... They are mainly designed to use in a postfix content scanner context. Only the redsky_sqlconn filter is required for mailinglist manager.

* mlm-filters (http://aur.archlinux.org/packages.php?ID=24399)

This is the most interesting set of filters. Mlm stands for Mailing List Manager. There's a queueing part and a sending part.

For the queueing part:
* mlm_getinfo: Fetch information for a certain list using SQL
* mlm_loopdetect: Check if a message is looping or not
* mlm_bouncehandler: If the message received was sent to a bounce address, store it in an SQL table
* mlm_getsubscribers: Get the subscribers from SQL for the current list
* mlm_access: Determine if a sender has access to the list. It currently supports 4 methods: use an ACL, only allow subscribers, require a passphrase or no limitations
* mlm_subjecttag: Tag the subject if the mailinglist is configured for that
* mlm_addfooter: Add a footer to the emails if the mailinglist is configured for that
* mlm_queuer: Write a spoolfile and put all the recipients into an SQL table

For the sending part:
* mlm_singleinstance: Only allow a single instance of redsky to be run
* mlm_queuebuilder: Build a queue of messages to be sent and their respective recipients
* mlm_queuerunner: Process the earlier built queue using sendmail to send messages


redsky is written to support multiple configurations. In the MLM case, you would have two configuration files (examples are shipped with mlm-filters), one for the queuer and one for the sender. The queuer would be called by the MTA while to sender could be executing with a cronjob. Use -c to supply an alternate config, for example:

redsky -c /etc/redsky.queuerunner.config.php



You will notice that the redsky-filters and mlm-filters come shipped with example configuration files. You will find them in /usr/share/php/redsky/. Some filters depend on each other, so it is important in which order they are executed. For example, the mlm_access cannot determine if the sender is a subscriber when mlm_getsubscribers hasn't run first, because it uses the information from mlm_getsubscribers for this.


Now maybe the hardest part, integration with an email server. I'll only handle postfix. Our entire infrastructure is based on MySQL, however all redsky code is written to use PDO, so it should be compatible with any databaseserver that PDO supports.

You can get our database schema from http://projects.webmind.be/redsky/mail.sql

In postfix terms, you would add entries to your alias table to send certain addresses to the "mlm". The examples below are made to work with the database schema above, but all queries can be modified in the configuration files.

virtual_alias_maps = mysql:/etc/postfix/mysql/lists.cf

lists.cf:

user = USER
password = PASSWORD
hosts = HOST
dbname = MAILDB

query = SELECT
'mlm' AS goto
FROM
lists
LEFT JOIN
domains
ON
domains.domain_id = lists.domain_id
WHERE
(lists.list_post_address = '%u' OR
lists.list_bounce_address = '%u') AND
domains.domain_name = '%d' AND
domains.domain_type = 'virtual' AND
domains.domain_enable_email = 'yes'

The above will send all mail sent to a mailing list address to 'mlm'.


Now postfix knows it needs to send any list emails to mlm. Now we need to tell postfix that all email sent to the local 'mlm' address to be piped to our mlm program. For this we create a transport table, that has 'mlm@localhost.localdomain' transported to the 'mlm' destination.

Now we have to define what the mlm destination is. Open up master.cf and add:

mlm unix - n n - - pipe
user=nobody flags=O argv=/usr/bin/redsky -c /etc/redsky.queuer.config.php

Note the O flag, this will add an X-Original-To header, which is required to identify wich original address the message was sent to.


To allow the messages to be distributed, just call /usr/bin/redsky -c /etc/redsky.runner.config.php

Ok, all this information was probably hard to swallow. I will try to answer any questions you have regarding the implementation. If you want to ask me a direct question you can find me on IRC, freenode with the nick RedShift. I am in #archlinux.

It's also easier if you start by testing it out directly from the shell instead of immediatly integrating it into your MTA.


Best regards,

Glenn
 
Old 03-03-2009, 08:14 PM
RedShift
 
Default mailman hiccup

Geoffroy Carrier wrote:

On Tue, Jan 20, 2009 at 09:10, RedShift <redshift@pandora.be> wrote:

I've been working on my own mailing list manager, it's completely written in
PHP and uses SQL as a backend, but at this point a bit specific to our
setup. Because our company is all about open source I intend on releasing it
as such. It's in need of an overhaul anyway, I'll get hacking at it again
ASAP.


I'd love to be an early adopter

Plus I'd be happy to contribute...





Ok so here's what I've got so far:


When I was designing my anti-SPAM filter, I noticed you're just running a series of code after each other. To keep everything nice and tidy I split up the various routines into small pieces of code designed to do one thing and then pass on to the next filter. My project has the codename "redsky". Yes, it's cliché but I couldn't think of anything else.

By itself, redsky is pretty useless. It's only capable of running a series of filters after each other. The real power is in the filters itself. The 3 filters that come shipped with redsky are designed to interface with another piece of software called proxsmtpd (but can be used in other ways as well, they just use STDIN and STDOUT), but there's no reasons you could write your own input/output filters and make redsky a mini-SMTP server.


Here are the packages that are of interest:

* phpemailtoolbox (http://aur.archlinux.org/packages.php?ID=22237)

This is a small set of email related functions and classes. It is required by redsky.

* redsky (http://aur.archlinux.org/packages.php?ID=22261)

This is the main redsky code. It contains three filters:
* redsky_read: this reads the email in question from STDIN. It is designed for interfacing with proxsmtpd, but can be used in a generic manner as well.
* redsky_discard: when the discard flag is set on an email, this filter will log this event.
* redsky_out: this outputs the email to STDOUT, again designed to interface with proxsmtpd but is suitable for general purpose as well. In the mailinglist

* redsky-filters (http://aur.archlinux.org/packages.php?ID=24393)

This is a set of complementary filters for redsky, it has for example SMTP blacklist checking, whitelisting, autoreplies, etc... They are mainly designed to use in a postfix content scanner context. Only the redsky_sqlconn filter is required for mailinglist manager.

* mlm-filters (http://aur.archlinux.org/packages.php?ID=24399)

This is the most interesting set of filters. Mlm stands for Mailing List Manager. There's a queueing part and a sending part.

For the queueing part:
* mlm_getinfo: Fetch information for a certain list using SQL
* mlm_loopdetect: Check if a message is looping or not
* mlm_bouncehandler: If the message received was sent to a bounce address, store it in an SQL table
* mlm_getsubscribers: Get the subscribers from SQL for the current list
* mlm_access: Determine if a sender has access to the list. It currently supports 4 methods: use an ACL, only allow subscribers, require a passphrase or no limitations
* mlm_subjecttag: Tag the subject if the mailinglist is configured for that
* mlm_addfooter: Add a footer to the emails if the mailinglist is configured for that
* mlm_queuer: Write a spoolfile and put all the recipients into an SQL table

For the sending part:
* mlm_singleinstance: Only allow a single instance of redsky to be run
* mlm_queuebuilder: Build a queue of messages to be sent and their respective recipients
* mlm_queuerunner: Process the earlier built queue using sendmail to send messages


redsky is written to support multiple configurations. In the MLM case, you would have two configuration files (examples are shipped with mlm-filters), one for the queuer and one for the sender. The queuer would be called by the MTA while to sender could be executing with a cronjob. Use -c to supply an alternate config, for example:

redsky -c /etc/redsky.queuerunner.config.php



You will notice that the redsky-filters and mlm-filters come shipped with example configuration files. You will find them in /usr/share/php/redsky/. Some filters depend on each other, so it is important in which order they are executed. For example, the mlm_access cannot determine if the sender is a subscriber when mlm_getsubscribers hasn't run first, because it uses the information from mlm_getsubscribers for this.


Now maybe the hardest part, integration with an email server. I'll only handle postfix. Our entire infrastructure is based on MySQL, however all redsky code is written to use PDO, so it should be compatible with any databaseserver that PDO supports.

You can get our database schema from http://projects.webmind.be/redsky/mail.sql

In postfix terms, you would add entries to your alias table to send certain addresses to the "mlm". The examples below are made to work with the database schema above, but all queries can be modified in the configuration files.

virtual_alias_maps = mysql:/etc/postfix/mysql/lists.cf

lists.cf:

user = USER
password = PASSWORD
hosts = HOST
dbname = MAILDB

query = SELECT
'mlm' AS goto
FROM
lists
LEFT JOIN
domains
ON
domains.domain_id = lists.domain_id
WHERE
(lists.list_post_address = '%u' OR
lists.list_bounce_address = '%u') AND
domains.domain_name = '%d' AND
domains.domain_type = 'virtual' AND
domains.domain_enable_email = 'yes'

The above will send all mail sent to a mailing list address to 'mlm'.


Now postfix knows it needs to send any list emails to mlm. Now we need to tell postfix that all email sent to the local 'mlm' address to be piped to our mlm program. For this we create a transport table, that has 'mlm@localhost.localdomain' transported to the 'mlm' destination.

Now we have to define what the mlm destination is. Open up master.cf and add:

mlm unix - n n - - pipe
user=nobody flags=O argv=/usr/bin/redsky -c /etc/redsky.queuer.config.php

Note the O flag, this will add an X-Original-To header, which is required to identify wich original address the message was sent to.


To allow the messages to be distributed, just call /usr/bin/redsky -c /etc/redsky.runner.config.php

Ok, all this information was probably hard to swallow. I will try to answer any questions you have regarding the implementation. If you want to ask me a direct question you can find me on IRC, freenode with the nick RedShift. I am in #archlinux.

It's also easier if you start by testing it out directly from the shell instead of immediatly integrating it into your MTA.


Best regards,

Glenn
 

Thread Tools




All times are GMT. The time now is 07:48 PM.

VBulletin, Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org