looking for beta tester: attachment-move custom handler
Hi,
I'm looking for beta tester for my custom Handler. Before to put it in production for my client.
I've setup a list here:
http://mailman.opensource-expert.com/mailman/listinfo/attachment-move
Subscribe and post attachment. They're supposed to be detached and posted to a remote hosting.
The email content is modified, a link to the moved content is added in txt and html.
Give it a try. I faced a bug with mixed encoding. Normally this is corrected. You can make it crash… Go ahead. If it crashes nothing is delivered.
The handler is installed in the pipeline that way:
# inserting in the pipeline mlist.pipeline = [ 'SpamDetect', 'Approve', 'Replybot', 'Moderate', 'Hold', # inserting the Handler here. 'AttachmentMove', 'MimeDel', 'Scrubber', 'Emergency', 'Tagger', 'CalcRecips', 'AvoidDuplicates', 'Cleanse', 'CleanseDKIM', 'CookHeaders', 'ToDigest', 'ToArchive', 'ToUsenet', 'AfterDelivery', 'Acknowledge', 'ToOutgoing', ]
Feedback are welcome.
The github repository doesn't host the last revision yet. The documentation for installation needs update too.
Sylvain.
Hi,
We have done some tests. Thanks people testing it.
Le 01/06/2014 11:38, Sylvain Viart a écrit :
I'm looking for beta tester for my custom Handler. http://mailman.opensource-expert.com/mailman/listinfo/attachment-move
Hosting in done in France and could be slow to reach from foreign countries.
I've updated the code and the doc https://github.com/Sylvain303/mailman-AttachmentMove
The remaining problems:
=> content encoding. If you send an email encoded in us-ascii it is rewritten in utf-8 to handle the text footer.
For some unknown reason (to me) the part are now base64 encoded (may be due to multi-byte characters). Is it a bad thing for spam detection that the content is base64? Or should I let it that way.
I've disabled the use of the borrowed calculate_attachments_dir(mlist, msg, msgdata) function. As it creates unique name but only for a single message. Attachment are now stored locally on a dedicated folder 'attachments-moved' next to 'attachments' used by Scrubber.py.
This ensure unique filename on the remote storage.
Of course it introduces storage and inode fillup… => Is there some cron or scheduled code available?
There's a crontab.in an also one installed by the debian package.
=> About translation of the footer, what is the procedure? I found a huge: http://wiki.list.org/display/DEV/Managing+Translations http://wiki.list.org/display/DEV/i18nhowto
I don't know if I will manage to write a human bearable procedure to install translation as well…
Regards, Sylvain.
On 06/02/2014 02:41 AM, Sylvain Viart wrote:
The remaining problems:
=> content encoding. If you send an email encoded in us-ascii it is rewritten in utf-8 to handle the text footer.
For some unknown reason (to me) the part are now base64 encoded (may be due to multi-byte characters). Is it a bad thing for spam detection that the content is base64? Or should I let it that way.
base64 is the default encoding for utf-8 in the Python email library. See <https://docs.python.org/2/library/email.charset.html>.
...
Of course it introduces storage and inode fillup… => Is there some cron or scheduled code available?
To do what?
There's a crontab.in an also one installed by the debian package.
Mailman has several scripts in its cron directory which need to be run by cron to provide various functionality. The GNU Mailman distribution includes cron/crontab.in which is intended to be installed as the Mailman user's crontab. Various packages may modify this and may install it as a system rather than a user crontab.
=> About translation of the footer, what is the procedure? I found a huge: http://wiki.list.org/display/DEV/Managing+Translations http://wiki.list.org/display/DEV/i18nhowto
I don't know if I will manage to write a human bearable procedure to install translation as well…
The procedure uses Mailman's i18n._() function (an implementation of gettext plus interpolation of variables) to map English strings into their target language translations using a message catalog for the target language. See, e.g., <http://en.wikipedia.org/wiki/Gettext>.
Basically, the procedure is to code all your strings in English within the i18n._() function. Then in Mailman's messages directory, run
make marked.files
to add your handler to the list of files that have strings to be translated ...
make potfile
to update the mailman.pot template file, and finally, just
make
to msgmerge the mailman.pot with the various message catalogs, or just e.g.
msgmerge fr/LC_MESSAGES/mailman.po
to do just French.
Then you edit the mailman.po to add the translations of the new strings and use msgfmt or Mailman's bin/msgfmt.py to compile the mailman.po into the binary mailman.mo for the target language and install it.
Note that if you are thinking about i18n from the point of view of your process being ultimately incorporated into the Mailman distribution, I think your use case is not of sufficient general interest to warrant that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Le 03/06/2014 06:18, Mark Sapiro a écrit :
Of course it introduces storage and inode fillup… => Is there some cron or scheduled code available?
To do what?
Purging old files.
I'm digging the way I should document the installation process. As this Handler is suppose to introduce easiness, after this installation, installing it is quite hard. So, I guess I should also provide a purge. A single oneliner bash script may accomplish this goal.
Note that if you are thinking about i18n from the point of view of your process being ultimately incorporated into the Mailman distribution, I think your use case is not of sufficient general interest to warrant that.
The purpose of attachment-move is to:
Integrate remotely (server side) the behavior of hosting the
attached file online (cloud hosting if you want). Mailman doesn't
provide yet a /simple way/ to do that. But I found the behavior of
the whole mailing list very powerful, but very complicated for basic
user.
User who knows how to attach a document, but certainly not how to
upload it somewhere, and even know less how to link it back in the
email. And even lesser the impact of sending this attachment to
hundred or thousand peoples… No to speak about the headache of the
administrator to keep is hosting delivering email…Your advise about i18n are good thanks. My question was more about how to translate part of the text inserted in the mail. As I use the Handler for French an English on the same server…
Your indication seems to confirm, that integrating translation on an external Handler seems hard enough to make it fail most list administrator.
By the way, your reply on gettext an make command is excellent, an would probably help googling for such topic. Given this information and also because of the text I use is so small, I may pass it by the list configuration first.
mlist.translation_attachment_moved = 'Attachment available here:'
Of course if the list is multi-language it wont work. But it can be a good start.
Thank you, for your valuable help. Regards, Sylvain. __
I'm looking for beta tester for this custom mailman's Handler. http://mailman.opensource-expert.com/mailman/listinfo/attachment-move Hosting in done in France and could be slow to reach from foreign countries. Open Source code and installation doc here: https://github.com/Sylvain303/mailman-AttachmentMove
participants (2)
-
Mark Sapiro -
Sylvain Viart