http://permalink.gmane.org/gmane.mail.mlmmj.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.mail.mlmmj.general/1373 <pre> OK, cool. Sorry I couldn't be any more help! Smiles, Ben. </pre> Ben Schmidt 2013-03-18T00:10:16 http://permalink.gmane.org/gmane.mail.mlmmj.general/1372 <pre> Yes, that's correct. I suggest that if you want to have a separate discussion without the external user, though, the correct thing to do would be to forward their message to the mailing list, discuss it on-list, and then have someone reply to the *original message* when the discussion is complete. If the external user is not actually involved in the discussion, they won't be replying all that often, so it shouldn't be a big hassle if they reply to an individual rather than to the list address; but the internal replyer can always set a Reply-To header to ensure subsequent replies go to the list if they want to. By replying to the external user's original message, you also ensure it appears in the correct thread/conversation from their point of view. Most MUAs these days have separate 'Reply List', 'Reply' and 'Reply All' buttons, so this is fairly easy for internal users--you can hand out the list address to external users who may have questions, and the internal users can discuss by using 'Reply List' or g</pre> Ben Schmidt 2013-03-16T23:05:13 http://permalink.gmane.org/gmane.mail.mlmmj.general/1371 <pre> It would. But that way every subscriber is able to instantly see the mistake and step in. Didn't think about that... Nice idea. But I want the possibility to discuss stuff from external people to find an appropriate answer and afterwards send out the reply on request. Your solution is only half way by having several people being able to reply and seeing each other's reply. As I understand your suggestion any reply to such a mail from outside would also go outside. </pre> Sebastian Lipp 2013-03-15T15:54:18 http://permalink.gmane.org/gmane.mail.mlmmj.general/1370 <pre> Ah, yes. That is a problem. This is an interesting use case indeed. However, doesn't your solution also require subscribers to take manual action? They would need to add the X-RESEND-TO: $external_recipient directive to the mail body. It's also not completely easy to parse mail bodies. They can be base64 encoded, etc., have multiple MIME alternatives (e.g. plain text and HTML, and the order isn't always the same), and it all depends on the user's MUA. I wonder if we can think of a better solution. One thought I have is this: Make Mlmmj, for *non-subscribers only* set a variable Reply-To header including the extra recipient. So the external sender would send a message to Mlmmj, and Mlmmj would send that message to all list subscribers with a header something like Reply-To: mylist+cc-external_address=theirdomain.tld-3Q2Tfjf0mewVpVtQvJkt/w&lt; at &gt;public.gmane.org so when someone replies, it would go to the list address with additional information after the delimiter. Mlmmj would receive the reply a</pre> Ben Schmidt 2013-03-15T14:47:53 http://permalink.gmane.org/gmane.mail.mlmmj.general/1369 <pre> Yes. I already thought about that setup. The Problem here is that the external sender will get a mail that never went to the mailing list and thus won't have the Reply-To header unless all subscribers set it manually. I suspect that this will work without problems. So the reply of the external guy will not reach the list. I really appreciate that you think about this. </pre> Sebastian Lipp 2013-03-15T13:13:55 http://permalink.gmane.org/gmane.mail.mlmmj.general/1368 <pre>I don't think I fully understand the problem. Wouldn't a traditional mailing list with a Reply-To header be sufficient for your needs? Those on the mailing list would know to use the Reply-All button to reply to both the list and the external sender, and the external sender could just use Reply to reply to the list. Is there something I am missing? Ben. On 5/03/13 1:27 AM, Sebastian Lipp wrote: </pre> Ben Schmidt 2013-03-15T11:38:11 http://permalink.gmane.org/gmane.mail.mlmmj.general/1367 <pre> We have a webserver configuration problem at present; it should be fixed shortly. In the meantime, you will find that mlmmj.org/archive/index.php works; once you click on the links there, you will also have to add /index.php to the end of the URL for it to work, too. Ben. </pre> Ben Schmidt 2013-03-14T00:15:53 http://permalink.gmane.org/gmane.mail.mlmmj.general/1366 <pre>Hello, Is there any archive for this list? mlmmj.org/archive shows a 404. I am tempted to send a string of mlmmj+gets... </pre> Piotr Auksztulewicz 2013-03-11T13:03:58 http://permalink.gmane.org/gmane.mail.mlmmj.general/1365 <pre>Hey there I'm running several mailing lists with mlmmj and absolutely satisfied with this great piece of software. But there is one capability that would make me love mlmmj even more. Theres a project where several people are involved. At the moment I'm the only one receiving it's mail. I'd like to have all mails forwarded to the project's mailing list to rise transparency and distribute the burden of dealing with mail to everyone involved. The problem with just forwarding and then cc-ing replies to outside people is that their replies won't be directed to the list but to the sender of the original reply. I can think of a solution. If mlmmj parsed the mail's body and added $external_recipient to the list of recipients if the first non-empty body line was X-RESEND-TO: $external_recipient I'd be satisfied. Unfortunately my understanding of C is far from beeing good enough to make such a change to mlmmj's code, though I can imagine that this would just add a few lines of code while introducing a great new</pre> Sebastian Lipp 2013-03-04T14:27:12 http://permalink.gmane.org/gmane.mail.mlmmj.general/1364 <pre>Hi everyone. I've posted some time ago this bug report: http://mlmmj.org/bugs/bug.php?id=33 along with some patches, fixing mlmmj behavior regarding the envelope/mail from address. I've been using these patches ever since to fix gmane (which I use for all my mailing lists). Got the first complaint today from a user coming from a BATV address: http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation this is news to me. As was discussed before: http://article.gmane.org/gmane.mail.mlmmj.general/1277 this clearly requires re-reading a whole lot of stuff now. It has been several years since I stopped lurking on nanae, but so far SPF/DKIM have been completely transparent. Doesn't seem to be the same for BATV. ezmlm seem to have the same issue, since it processes addresses according to the envelope from, and not from the "From:" header. I've been trying to read what exactly mailman does, as mailman also uses (used to) to process addresses based on the envelope address, but I stopped becau</pre> Yuri D'Elia 2012-06-01T13:08:50 http://permalink.gmane.org/gmane.mail.mlmmj.general/1363 <pre> Done! Thomas </pre> Thomas Goirand 2012-05-30T17:40:26 http://permalink.gmane.org/gmane.mail.mlmmj.general/1362 <pre> It's totally possible to just use path - but it's a security question. The less you need to parse things from the environment, the better. </pre> Mads Martin Jørgensen 2012-05-30T14:17:20 http://permalink.gmane.org/gmane.mail.mlmmj.general/1361 <pre> I always just patch away this code completely when I build mlmmj. Like almost everyone else, I don't build systems with multiple versions of mlmmj on my path, and have always found the UI breakage of requiring absolute paths on the command line because someone might do something that weird completely bonkers. Cheers, Chris. </pre> Chris Webb 2012-05-30T14:17:15 http://permalink.gmane.org/gmane.mail.mlmmj.general/1360 <pre> Excellent! Yeah, that's really stupid. We should be able to get the prefix in a macro in config.h if nothing else. Could you possibly jump on the bug tracker at http://mlmmj.org/bugs/report.php and add this as a bug, and upload the patch (even though this patch doesn't fix the bug, it demonstrates and localises the problem)? Then I should get around to it before the next release if not before. One day we might even fix things so you don't need to use the full path to invoke the binaries. I certainly find it really annoying, and I don't know any other application that requires it. You'd think we could figure out what's going on from argv[0] or something. Yeah, I agree. It's really an example file anyway. You just have a more Debian-specific example. There will be no one-size-fits-all for this. Ben. </pre> Ben Schmidt 2012-05-30T14:00:55 http://permalink.gmane.org/gmane.mail.mlmmj.general/1359 <pre> The auto-* macros should substitute this to always Say The Right Thing[tm]. </pre> Mads Martin Jørgensen 2012-05-30T13:45:04 http://permalink.gmane.org/gmane.mail.mlmmj.general/1358 <pre> Hey, that's just on time for Debian 7 (code name: Wheezy)! Thanks for that. I've updated the Debian packages today, and uploaded to SID, if everything goes well, it's going to be in Wheezy. I'm quite happy to see that I had to remove most of the Debian specific patches, as they were incorporated upstream (eg: on mlmmj original sources). Still, there are 2 patches remaining. I believe that this one could be somehow avoided: --- a/include/mlmmj.h2012-01-22 15:36:11.000000000 +0800 +++ b/include/mlmmj.h2012-01-22 15:36:16.000000000 +0800 &lt; at &gt;&lt; at &gt; -88,7 +88,7 &lt; at &gt;&lt; at &gt; #define CHECKFULLPATH(name) if(strchr(name, '/') == NULL) { \ fprintf(stderr, "All mlmmj binaries have to " \ "be invoked with full path,\n" \ -"e.g. /usr/local/bin/%s\n", name); \ +"e.g. /usr/bin/%s\n", name); \ exit(EXIT_FAILURE); \ }; what do you think? The other one is contrib/web/php-admin/htdocs/dot.htaccess: diff -u -r -N a/contrib/web/php-admin/htdocs/dot.htaccess b/contrib/web/php-admin/htdocs/dot.htaccess --- a/co</pre> Thomas Goirand 2012-05-30T13:30:56 http://permalink.gmane.org/gmane.mail.mlmmj.general/1357 <pre>Hi, everybody! I am pleased to announce that Mlmmj 1.2.18.0 has been released. Find it on the downloads page[1]. This version contains a number of important new features: - Richer list texts (including a new naming scheme, conditionals, automatic wrapping and true UTF-8 support). See README.listtexts for more details. - Notifying posters when their posts are being moderated (notifymod tunable). - Not-me-too feature to avoid having the poster receiving their own messages (notmetoo tunable). - Ability to explicitly reject posts (exposed in new list texts). - Ability to explicitly obstruct subscriptions (exposed in new list texts). - Unsubscribe from all versions of a list at once (changed behaviour of +unsubscribe[-{digest|nomail}]; they now all remove the subscriber from all versions of the list). - Ability to switch between different versions of a list by using +subscribe[-{digest|nomail|both}] ('both' means normal and digest, and is a 'hidden feature' not mentioned in the suppl</pre> Ben Schmidt 2012-05-29T14:14:38 http://permalink.gmane.org/gmane.mail.mlmmj.general/1356 <pre>Hi, people. Any feedback on the release candidate, positive or negative? I'll probably let it out the door this weekend. Ben. On 3/05/12 10:37 AM, Ben Schmidt wrote: </pre> Ben Schmidt 2012-05-16T13:48:43 http://permalink.gmane.org/gmane.mail.mlmmj.general/1355 <pre>Hi, Christian, Have a look at this thread: http://mlmmj.org/archive/mlmmj/2012-03/2096.html The question was asked for a different reason, but I think the answers will apply to you. Smiles, Ben. On 14/05/12 8:33 AM, Christian wrote: </pre> Ben Schmidt 2012-05-14T00:27:04 http://permalink.gmane.org/gmane.mail.mlmmj.general/1354 <pre>Hello list I asked this question some time ago, but never concluded anything (And i don't know how to reply to the old thread since it is not in my inbox anymore, I will just add a link to the archive, hope thats ok:) ) http://mlmmj.org/archive/mlmmj/2011-06/1993.html Anyways. We are using mlmmj as for sending newsletters, lots of users, more than 10k. sometimes the are problems delivering messages to some user. of course this is bad. However, we would prefer that the users users does not get any "some messaged could not be delivered. If you see this things are back to normal." mails. Last time, ben asked be to look into the last bounce something, I did that, and apparently there had ben some problems at the users ISP end... I would prefer, that mlmmj didn't inform the users that there are problems, the mails are not so important that skipping a few will do any harm, where as informing the user that there was technical problems that they otherwise wouldn't know about, makes them sad and or angry... I</pre> Christian 2012-05-13T22:33:35 http://permalink.gmane.org/gmane.mail.mlmmj.general/1353 <pre> Hi, Theo, Yes, I'd quite probably accept such a change, provided it is kept simple, and particularly if some specifics are floated past the mailing list prior to preparing a patch, so people have a chance to raise any issues. There are also some pending changes to header stuff in the bug tracker, so it would be good to at least keep those in mind, or even implement them along with the new code (probably in separate patches, but nonetheless, the work is related and might be good to be implemented together). Cheers, Ben. </pre> Ben Schmidt 2012-05-11T14:56:39 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.mlmmj.general