Free software mailing lists suck. Especially Apache’s.
- Many of them have a CRAP Web interface or worse:
- Posting limited to subscribers
For weeks I have been struggling with Apache mailing lists (apache-users and spamassassin) and now recently with mutt lists.
I know with Apache lists you can use a special syntax:
You can start a subscription for an alternate address, for example "john@host.domain", just add a hyphen and your address (with '=' instead of '@') after the command word: <users-subscribe-john=host.domain@httpd.apache.org>
But when I do it via mutt or a `echo test | mail users-unsubscribe-hendry=dabase.com@httpd.apache.org`. I get no response from the automated mailing list manager. 
So, If I ever get subscribed it’s generally thanks to the mailing list owner.
Then after lurking a bit, I try post. That never works as the return paths don’t match the email I am subscribed with. Return paths change all the time depending on which machine I sent it from. It could be anything from:
- hendry@pico.dreamhost.com (from my shell)
- hendry@laptop.dabase.com (from my laptop)
- hendry@soltecsoftware.com.au (from work)
And the first two aren’t working email addresses!
If you must filter, can’t you filter on my From OR Reply-To email address FFS: hendry@iki.fi
All I suggest is for Apache to start using something usable like Google Groups for user support.
Does anyone else feel my frustration?
But aren’t non-working return paths even worse? “From” is often bogus, but if your return-path is not working, you won’t be receiving error messages and such. Better fix that first.
I agree that there should be a way to subscribe with alternative email adresses, too. Especially do write-only subscriptions, if you are using multiple emails or using web archives to read.
I don’t like Google Groups. Everything web-based sucks.
The return path is more reliable in my case actually. I hate any list that uses From or Reply-To.
Because evolution lacks any configuration option to say “whenever I post to this list, use that from” (mutt does have such functionality). So I end up posting to some lists with varying From adresses. I hate when my email comes back then… the “minit” mailing list is such an example.
The proper approach is actually to just moderate emails from non-subscribers… not outright reject the mails.
I don’t know what to make of return paths. They’re generated by the MTA aren’t they? Some MTAs aren’t accessible (behind firewalls) like my laptop’s. And besides, I want my email sent to my From: or Reply-To: address ffs!
I don’t see why we can think that return-paths are legitimate and From: bogus. That’s daft.
Moderation. It just doesn’t seem to work ever IMHO. From emails to IRC. It just sucks.
Google Groups? Usable? Please tell me you are joking.
Current irritation is that Google Groups seems to have blacklisted entire TLDs, including my usual one for mailing lists. I’ve never had a reply from their support. Google really doesn’t care about usability, as far as I can tell.
Mailman isn’t a good web interface, but at least much of it is emailable too. There are other list servers out there, some of which behave better, but none I like much today.
On the return paths: yes, the MTA usually generates them, but it should set them to working email addresses. The not-always-accessible and more location-specific identifiers should be in the Sender header, not the envelope/return path. If your MTA doesn’t set a working return path, it’s misconfigured.
Why are envelope/return paths useful? They’re sent in the SMTP conversation, so they can be used without needing to parse the message headers. It’s not that your headers aren’t trusted, just that it’s not as easy. I doubt a good listserver should use them much, though, as surely most have header-parsing routines available.
Well, From: is just the visible sender.
Return-Path is the specification where to return bounces to.
FYI: my mailserver will reject mails with a return-path that contains a non-resolveable hostname.
Note that both exim (use /etc/email-adresses) and postfix (use canonical maps) allow you to configure rewriting for your return path.
To be precise: neither the “From:” nor the “To:” field have any real importance in SMTP. Thats why stuff like CC: and Bcc: and forwarding work. The real sender (read: return) and reciepient adresses are transmitted in the SMTP handshake. They are only “logged” to the mail headers, actually.
(see SMTP “MAIL FROM” and “RCPT TO” commands)
The return-path is by definition the contents of the “MAIL FROM:” part of the smtp handshake.
The firewall argument is bogus. Thats what an MX is for. Setup an MX so it receieves and forwards/stores the return mail for you.