
We're considering enabling the scrub_nondigest option for our list. The aim is to allow members to send jpg files to the list (currently filtered) and have mailman include a link to them in messages instead of the actual attachment. I've got a few questions about how this works.
I believe it will store the scrubbed images in the archives. We have archiving turned off. Do we need to turn them on to allow the images to be placed there, or will it happen anyway?
Once we have images stored in the archives, how easy is it for members to access them when they click on the links in the messages? Will they need a password to see them?
Will we be able to selectively delete images when our disk space begins to fill up? Or will they all be stored in a single archive file? We're using cpanel, if that matters.
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated.
Sent from my iPad

On 06/22/2014 05:21 PM, Peter Shute wrote:
We're considering enabling the scrub_nondigest option for our list. The aim is to allow members to send jpg files to the list (currently filtered) and have mailman include a link to them in messages instead of the actual attachment. I've got a few questions about how this works.
I believe it will store the scrubbed images in the archives. We have archiving turned off. Do we need to turn them on to allow the images to be placed there, or will it happen anyway?
It will happen anyway. Archiving for the list doesn't need to be enabled.
Once we have images stored in the archives, how easy is it for members to access them when they click on the links in the messages? Will they need a password to see them?
If and only if the list's archive_private setting is private, but since archiving is Off, if you want scrubbed attachments accessible without autnentication, just set archive_private to public.
Will we be able to selectively delete images when our disk space begins to fill up? Or will they all be stored in a single archive file? We're using cpanel, if that matters.
I don't think cPanel is different.
The attachments for a message are stored individually in the directory archives/private/LISTNAME/attachments/yyyymmdd/xxxxxxxx/. yyyymmdd is the date and xxxxxxxx is a hash of the message, so you can delete individual files or the xxxxxxxx directory for all attachments for a single message or the yyyymmdd directory for all attachments from a given day.
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated.
Why not just try it yourself on a test list?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 23 Jun 2014, at 4:08 pm, "Mark Sapiro" <mark@msapiro.net> wrote:
Will we be able to selectively delete images when our disk space begins to fill up? Or will they all be stored in a single archive file? We're using cpanel, if that matters.
I don't think cPanel is different.
The attachments for a message are stored individually in the directory archives/private/LISTNAME/attachments/yyyymmdd/xxxxxxxx/. yyyymmdd is the date and xxxxxxxx is a hash of the message, so you can delete individual files or the xxxxxxxx directory for all attachments for a single message or the yyyymmdd directory for all attachments from a given day.
Any idea if we'll have access to that area in cPanel? I'm not the list owner, I can't test it for myself.
And does the value of archive_volume_frequency affect where they're stored?
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated
Thanks for sending the sample.
Peter Shute

Hi Peter,
I programmed a custom handler that complete or replace Scrub_nondigest handler:
AttachmentMove
You can test or try it here: http://mailman.opensource-expert.com/mailman/listinfo/attachment-move
Hosting in done in France and could be slow to reach from foreign countries. This running version is not commited yet, minor i8n changes. It's also working in production of a customer with a list of 930 subscribers since 3 weeks.
The code and the doc : https://github.com/Sylvain303/mailman-AttachmentMove
Le 23/06/2014 10:03, Peter Shute a écrit :
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated
AttachmentMove keeps embedded images, they could be moved as well. The remote hosting for attachment can be same or a different one that the server running mailman.
To reply to your first post:
We're considering enabling the scrub_nondigest option for our list. The aim is to allow members to send jpg files to the list (currently filtered) and have mailman include a link to them in messages instead of the actual attachment.
That is the purpose of AttachmentMove.
I believe it will store the scrubbed images in the archives. We have archiving turned off. Do we need to turn them on to allow the images to be placed there, or will it happen anyway?
Attachment are stored "locally" and on a remote hosting. The local storage (on the mailman server) is not the archive. And it is used to avoid duplicate file name when uploaded on the webserver.
Once we have images stored in the archives, how easy is it for members to access them when they click on the links in the messages? Will they need a password to see them?
AttachmentMove, publish the image on a different hosting no password are required, the goal was to keeps user away for technical details.
Will we be able to selectively delete images when our disk space begins to fill up? Or will they all be stored in a single archive file? We're using cpanel, if that matters.
Not storage management is coded yet, a cron with the good "find -mtime" could do the trick. It's in my idea to handle that too.
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated.
I sent you an example we have made on the test list.
Let me know if that meet your needs.
Regards, Sylvain.

I was testing that for you a few weeks ago. I just tried again, and it seems to work smoothly now.
Could that be made to automatically resize images? E.g. maximum dimensions 800x800 pixels.
Peter Shute
Sent from my iPad
On 23 Jun 2014, at 7:30 pm, "Sylvain Viart" <sylvain@opensource-expert.com> wrote:
Hi Peter,
I programmed a custom handler that complete or replace Scrub_nondigest handler:
AttachmentMove
You can test or try it here: http://mailman.opensource-expert.com/mailman/listinfo/attachment-move
Hosting in done in France and could be slow to reach from foreign countries. This running version is not commited yet, minor i8n changes. It's also working in production of a customer with a list of 930 subscribers since 3 weeks.
The code and the doc : https://github.com/Sylvain303/mailman-AttachmentMove
Le 23/06/2014 10:03, Peter Shute a écrit :
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated
AttachmentMove keeps embedded images, they could be moved as well. The remote hosting for attachment can be same or a different one that the server running mailman.
To reply to your first post:
We're considering enabling the scrub_nondigest option for our list. The aim is to allow members to send jpg files to the list (currently filtered) and have mailman include a link to them in messages instead of the actual attachment.
That is the purpose of AttachmentMove.
I believe it will store the scrubbed images in the archives. We have archiving turned off. Do we need to turn them on to allow the images to be placed there, or will it happen anyway?
Attachment are stored "locally" and on a remote hosting. The local storage (on the mailman server) is not the archive. And it is used to avoid duplicate file name when uploaded on the webserver.
Once we have images stored in the archives, how easy is it for members to access them when they click on the links in the messages? Will they need a password to see them?
AttachmentMove, publish the image on a different hosting no password are required, the goal was to keeps user away for technical details.
Will we be able to selectively delete images when our disk space begins to fill up? Or will they all be stored in a single archive file? We're using cpanel, if that matters.
Not storage management is coded yet, a cron with the good "find -mtime" could do the trick. It's in my idea to handle that too.
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated.
I sent you an example we have made on the test list.
Let me know if that meet your needs.
Regards, Sylvain.

Hi Peter,
Le 23/06/2014 12:57, Peter Shute a écrit :
I was testing that for you a few weeks ago. I just tried again, and it seems to work smoothly now.
That's true, thanks. :-) You did just send a non html mail, right?
AttachmentMove also support html formating.
Could that be made to automatically resize images? E.g. maximum dimensions 800x800 pixels.
Yes it could.
At the stage where the image is detached it can be manipulated, including stored on some image cloud storage with other feature, like albums for example. Given that storage as an API that a programmer can use to store the image remotely.
With linux server there's plenty of tools for resizing image, with and without python.
If you don't need the remote simplification of AttachmentMove, you may also look at ThunderBird cloud storage FileLink extension.
Regards, Sylvain.

On 06/23/2014 01:03 AM, Peter Shute wrote:
Any idea if we'll have access to that area in cPanel? I'm not the list owner, I can't test it for myself.
It depends. In cPanel all Mailman files including the archives/private/ directory are in /usr/local/cpanel/3rdparty/mailman/. If this is the list owner's server or VPS, etc, he probably has the required access. If his is one of multiple hosted domains on a shared server, he almost certainly doesn't.
And does the value of archive_volume_frequency affect where they're stored?
No.
If anyone who's using this option could forward me a message from their list with a linked image so I can check how well it works, that would be greatly appreciated
Thanks for sending the sample.
You're welcome.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 24 Jun 2014, at 8:56 am, "Mark Sapiro" <mark@msapiro.net> wrote:
On 06/23/2014 01:03 AM, Peter Shute wrote:
Any idea if we'll have access to that area in cPanel? I'm not the list owner, I can't test it for myself.
It depends. In cPanel all Mailman files including the archives/private/ directory are in /usr/local/cpanel/3rdparty/mailman/. If this is the list owner's server or VPS, etc, he probably has the required access. If his is one of multiple hosted domains on a shared server, he almost certainly doesn't.
Ours is hosted. In this situation, what does one normally do? Ask the hosting company to delete them?
Peter Shute

On 06/23/2014 05:01 PM, Peter Shute wrote:
It depends. In cPanel all Mailman files including the archives/private/ directory are in /usr/local/cpanel/3rdparty/mailman/. If this is the list owner's server or VPS, etc, he probably has the required access. If his is one of multiple hosted domains on a shared server, he almost certainly doesn't.
Ours is hosted. In this situation, what does one normally do? Ask the hosting company to delete them?
Why bother? This file system belongs to the host. If it gets too full (unlikely), it's their problem. If they have some way of charging you for disk usage attributable to your list, then they should accommodate a request to remove some.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro
-
Peter Shute
-
Sylvain Viart