Mailman 3 April 1998 - Mailman-Developers

Re: Welcome To "CC-Mode-Announce"!
by Barry A. Warsaw 30 Apr '98

30 Apr '98

Dan, Mailman is fairly new, so development is continuing quickly. If you are really interested in discussing some of these issues, I suggest following up to mailman-developers(a)python.org. You can of course join this list in the usual Mailman ways <http://www.python.org/mailman/listinfo/mailman-developers> I hope you don't mind me CC'ing that list on this reply. I'd like for the wider Mailman developers audience to have a chance to respond. >>>>> "DH" == Dan Harkless <dharkless(a)unitech.com> writes: DH> I figured out what the problem is. Mailman does not use the DH> correct address. I send my mails from a local account called DH> "dlh", and I masquerade as "unitech.com", so my emails DH> (including this one) have this line: DH> Sender: dlh(a)unitech.com DH> However, my From line is set to my desired return address: DH> From: Dan Harkless <dharkless(a)unitech.com> DH> Right now there *is* a dlh(a)unitech.com, and that's where I DH> found mail from Mailman, but that account will soon go away. DH> Mailman is doing The Wrong Thing in preferring the Sender line DH> (or envelope sender information) over the From line. In these DH> days of POP mail boxes, people don't always send mail from the DH> same "account" (if such even exists) that receives it. I have never seen Sender used in this way. Typically Sender is used by a MLM to point to the list owner. Bounces will get sent to Sender, since the owner is the only person that can deal with such problems. In Mailman's case, the owner is a program that keeps track of bounces and auto-disables accounts that meet a certain threshold. I wasn't aware that Mailman uses the Sender address when deciding where to send replies. I agree it shouldn't use it, and certainly not in preference to From: or Reply-to: DH> What if I had my correct email address in the DH> even-higher-priority Reply-To line? Does it ignore that too? No. The order should be Reply-to (if present) followed by From. The list is currently debating whether Mailman should allow admins to Reply-to munge at all. We all (I think) agree it's evil, but there's some debate as to whether list admins should be allowed to configure it at all. DH> Is any of this behavior configurable? Not by users. DH> Actually I was just able to unsubscribe my old email address, DH> harkless(a)unitech.com, and it didn't ask me for my password. That's very strange. I just tried it with my own account and it definitely required a password. DH> I then re-subscribed with my new address, DH> dharkless(a)unitech.com, and it got as far as replying to the DH> verification email, but then I never heard back from the DH> server. I tried to go to the adjustments page for my new DH> address and it says that user doesn't exist. I can see that dlh(a)unitech.com is a member, not dharkless(a)unitech.com. I think that subscribing 3rd party addresses (essentially what you're doing) is something that Mailman currently doesn't support too well. It's being worked on though. If it's critical I think I can manually change the subscription to dharkless. >> If you forget your password, don't worry, you will receive a >> monthly reminder telling you what all your python.org maillist >> passwords are, DH> Hmm. That sounds pretty annoying. It'd be nice if there were DH> an option to turn that off. In practice it's not bad, but I agree. You can always get your password emailed to you via the Web interface. -Barry

1 0

Re: [Mailman-developers] reply-to munging
by John Viega 30 Apr '98

30 Apr '98

> >From the conversations about the reply-to issues, i propose changing > reply_goes_to_list so it will *not* cause user specified reply-to > headers, if present, to be replaced with the list's address. It just > does not seem valid to override the mechanism which is intended for > users to make their correct address available. > > Conversely, though using the reply-to at all in this way seems a bit > improper, it sounds like the functionality is really necessary for > some kinds of lists. (Perhaps i'm neglecting some alternate means for > implementing this that was mentioned?) > > This will apply at least to individual messages, while digests as a > whole will have the list as the reply-to addr. > > Objections? Yes, I object to that. Either the person sees why reply-to munging is bad, or he doesn't. If he doesn't, he's not going to want this behavior. Consistancy is important; there should not be differing behavior on a per-list basis when you hit "reply" based on the mail setup of the original sender. John

2 1

reply-to munging
by Ken Manheimer 30 Apr '98

30 Apr '98

>From the conversations about the reply-to issues, i propose changing reply_goes_to_list so it will *not* cause user specified reply-to headers, if present, to be replaced with the list's address. It just does not seem valid to override the mechanism which is intended for users to make their correct address available. Conversely, though using the reply-to at all in this way seems a bit improper, it sounds like the functionality is really necessary for some kinds of lists. (Perhaps i'm neglecting some alternate means for implementing this that was mentioned?) This will apply at least to individual messages, while digests as a whole will have the list as the reply-to addr. Objections? Ken

1 0

wrapper programs bug fix
by Ken Manheimer 29 Apr '98

29 Apr '98

There's a bug in the new version of the cgi-wrapper.c program, which the following patch fixes, and more. The bug appears on error reporting, when the invoking process UID or GID doesn't match the configured setting - then a "%s" in the error report string causes a segfault when it's mapped onto the LEGAL_PARENT_UID or _GID. While the fix is obvious (change the two occurrences of "%s" to "%d"), the patches do a bit more than that. They also change the type of the main() routine to int, since gcc seems to expect that. (When the type was void gcc complained about it not being an int, and i figure gcc knows what it's doing. I don't, when it comes to C. (...Caveat emptor...-)) Ken Index: cgi-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/cgi-wrapper.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** cgi-wrapper.c 1998/04/03 00:12:57 1.1 --- cgi-wrapper.c 1998/04/28 22:36:07 1.2 *************** *** 53,69 **** /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %s made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %s made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! void main(int argc, char **argv, char **env) { int i; --- 53,69 ---- /* compare to our parent's uid */ if(LEGAL_PARENT_UID != getuid()) { ! err("Attempt to exec cgi %d made by uid %d", LEGAL_PARENT_UID, getuid()); } if(LEGAL_PARENT_GID != getgid()) { ! err("Attempt to exec cgi %d made by gid %d", LEGAL_PARENT_GID, getgid()); } } ! int main(int argc, char **argv, char **env) { int i; Index: mail-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/mail-wrapper.c,v retrieving revision 1.5 retrieving revision 1.6 diff -c -r1.5 -r1.6 *** mail-wrapper.c 1998/03/30 16:28:22 1.5 --- mail-wrapper.c 1998/04/28 22:36:29 1.6 *************** *** 107,113 **** return 0; } ! void main(int argc, char **argv) { char *command; int i; --- 107,113 ---- return 0; } ! int main(int argc, char **argv) { char *command; int i; Index: alias-wrapper.c =================================================================== RCS file: /projects/cvsroot/mailman/src/alias-wrapper.c,v retrieving revision 1.3 retrieving revision 1.5 diff -c -r1.3 -r1.5 *** alias-wrapper.c 1998/03/05 23:46:45 1.3 --- alias-wrapper.c 1998/04/28 22:38:18 1.5 *************** *** 60,66 **** } } ! void main(int argc, char **argv, char **env) { char *command; int i; --- 60,66 ---- } } ! int main(int argc, char **argv, char **env) { char *command; int i; *************** *** 78,83 **** --- 78,85 ---- else { printf("Illegal caller!\n"); + return 1; } + return 0; }

1 0

Re: [Mailman-developers] forwarded message from Andrew Kuchling
by John Viega 28 Apr '98

28 Apr '98

> Ken Manheimer <klm(a)python.org> writes: > > > It looks like there may be a problem, or at least some sendmail > > (8.8.8) sensitivities, in the way that mailman is mime-encoding the > > digests. > > I have also received reports of 8.8.8 dumping core (probably) due to > MIME digests. Well, I will report this bug to the sendmail developer today. Can anyone give me more specifics, such as affected operating systems? > Some other mailers complain about the number of attachments. Over 20 > seems to be too much for them. That's sad. It is unfortunate that few mailers deal with MIME digests decently. When I added the feature to mailman, I was wondering why no other package supported MIME digests. I very quickly learned that it is probably because so few mailers support them well if at all. I got so many complaints about the MIME digests that were the mailer's fault, that it became really clear to me that MIME digests need to be off by default until other mail software improves. I think Ken changed the default in the release, but if I haven't said so before, I strongly believe it should be changed back. John

2 1

Re: [Mailman-developers] Bug: includes Reply-To in administrative messages
by John Viega 28 Apr '98

28 Apr '98

> Mailman should never add a Reply-to header. Please see the seminal > paper on this: > > "Reply-to" Munging Considered Harmful > <http://www.unicom.com/pw/reply-to-harmful.html> While I've certainly been a strong detractor of Reply-to ever since reading that article, there are still those who do not agree. I think adding the reply-to header should be an option, although it should be strongly discouraged. Ugh, I just went to the discussion forum off that page for the first time in quite a while. I see where well over a year ago I suggested that replies to a list should not be sent out to people who are in the TO or CC line (at least as an option). I'm pretty sure that feature is no longer in Mailman, and it should definitely go back in. If someone has time to Mailman hack in the near future, please consider adding that :) John

3 3

forwarded message from Andrew Kuchling
by Ken Manheimer 27 Apr '98

27 Apr '98

It looks like there may be a problem, or at least some sendmail (8.8.8) sensitivities, in the way that mailman is mime-encoding the digests. Does anyone have enough MIME acquaintance to have an immediate idea whether or not the current format is correct? In any case, i responded that i would look into the problem tomorrow, and plan to look into using the python distribution mime facilities - in particular mimify.py - to use known quantities for the encoding. Clues would be appreciated... ken manheimer klm(a)python.org From: postmaster(a)mch.sni.de To: xml-sig-admin(a)python.org Cc: Winfried.Magerl(a)mch.sni.de (Winfried Magerl), Roland.Schad(a)mch.sbs.de (Roland Schad), Helmut.Peisl(a)mch.sni.de (Helmut Peisl) Subject: Problems with list xml-sig Date: Fri, 24 Apr 1998 16:49:25 +0200 (MDT) Dear Adminstrator, we have a lot of trouble with your mail sent from xml-sig(a)python.org It crashes (memory fault) our sendmail V8.8.8 when it attempts to deliver the mail to our local receipient. Worse, it prevents processing the whole queue because it always stumbles over your mail and then it crashes. We have tried a few things and we found that the problems is one specific line in the messageheader: HContent-type: multipart/digest; boundary="__--__--" If we remove this line, everything works fine. We send and receive some ten thousand mails a day and never run into problems like this. Would you please alterate this line so this won't happen again. Thank you very much for your assistance in helping us to solve this problem. Sincerely, Gerald Rinske Postmaster -- Internet Administration Munich Siemens Business Services, 81739 Munich, Germany Internet-Mail: postmaster(a)mch.sni.de

3 3

access to admin pages
by Scott 27 Apr '98

27 Apr '98

i have a little concern about the ability to access administrative pages via the web without password confirmation. there are a number of pieces of displayed information that could lead spammers to view these pages and figure out how to spam lists. for example, anyone can get access to whether a list accepts posts from anyone. anyone can gain access to specific anti-spam measures a list has configured, anyone can gain access to bounce control measures about a list and determine whether or what kind of out of service attack may be possible. for all these reasons, and for the sake of the design of the administrative cgi script, it seems that it may be a good idea to stick the entire interface behind a single login and use cookies from there to allow access. the reason this seems better from a design point of view of the admin script is that i recently spent a good deal of time adding a separate type of authentication to one section. it was quite complicated, as the script was designed for authentication only when changes were requested. as more different things develop under the administrative interface, some of them will require authentication for viewing and some won't. changing around the authentication scheme every time will involve work. it would be much simpler just to have one login at the onset and to cookies from there. thoughts? scott

3 2

what to do with confirmation of web based subscriptions
by Scott 27 Apr '98

27 Apr '98

proposal concerning web based subscriptions: *allways* use confirmation, even if the list doesn't require them via email. If you don't, it's a security hole for any mailing list that doesn't implement it, and for out of service-attacks against the system mailman on which mailman is running. Even if a list is not advertised, it is still vulnerable to this, as an "attacker" could well find out the name of list by other means. it seems that as mailman becomes more widely used, more and more lists will have a problem with this. comments? Scott Cotton IC Group Inc

4 5

Re: [Mailman-developers] Subject line, Re:, subject prefix (a small patch)
by John Viega 27 Apr '98

27 Apr '98

One thing I've seen some mailers do which I have considered for mailman is to collapse Re: Re: into Re[2]: and Re: Re[n]: into Re[n+1]:. Any thoughts?

3 2

Mailman-Developers April 1998