Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachment with long filename can break list archives #699

Closed
dpc22 opened this issue Jul 18, 2019 · 2 comments · Fixed by #725
Closed

Attachment with long filename can break list archives #699

dpc22 opened this issue Jul 18, 2019 · 2 comments · Fixed by #725
Assignees
Labels
Milestone

Comments

@dpc22
Copy link
Contributor

dpc22 commented Jul 18, 2019

Version

Sympa 6.2.44
MHonARC 2.6.19

Installation method

rpm from https://copr.fedorainfracloud.org/coprs/xavierb/sympa/

Expected behavior

Message containing attachment should be saved to list archives

Actual behavior

mhonarc dies while trying to update a particular months archives:

Jul 17 15:18:34 lists-1 archived[27605]: err main::#162 > Sympa::Spindle::spin#83 > Sympa::Spindle::ProcessArchive::_twist#85 > Sympa::Spindle::ProcessArchive::_do_command#189 > Sympa::Spindle::ProcessArchive::_do_rebuildarc#285 > Sympa::Archive::html_rebuild#701 Command /usr/bin/mhonarc -addressmodifycode 1 -rcfile /etc/sympa/mhonarc-ressources.tt2 -outdir /var/lib/sympa/arc/[email protected]/2014-12 -definevars listname='soc-cssa' hostname=lists.cam.ac.uk yyyy=2014 mois=12 yyyymm=2014-12 wdir=/var/lib/sympa/arc base=https://lists.cam.ac.uk/sympa/arc tag=3648bc1eec with_tslice=1 with_powered_by=1 -umask 027 /var/spool/sympa/tmp/[email protected]/2014-12/arctxt failed with exit code 36

Additional information

Following on from #685, I thought that I would try migrating email from a high volume mailing list used by one of our Chineese language societies. This worked better than I feared, apart from a couple of messages which had silly attachment names, for example:

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
        name="=?UTF-8?B?44CQQ1NTQS1DQU3jgJHjgJDkuJbnlYzmmK/miYDmnIDmo5LnmoTlpKflrabigJTlrZnkuIDluIY=?=
        =?UTF-8?B?55qE5Lyg5aWH5pWF5LqL77yMMTIuNiBza3lsaW5l5bCx5Lia5oyH5a+86K6y5bqn77yM6aaW5bGKQ2Ft?=
        =?UTF-8?B?YnJpZGdlIENTU0Hnr67nkIPotZsoM3ZzMyzljZXmjJHvvIzkuInliIYp5Y+KQ1NTQeWNjuS6uuevrg==?=
        =?UTF-8?B?55CD6Zif6YCJ5ouU5oub5Yuf77yMMjAxNC4xMi4wNui2s+eQg+i/veaipuS6uu+8jFRFRHhA5YmR5qGl?=
        =?UTF-8?B?5aSn5a2m5ryU6K6y5ZiJ5a6+5oub5Yuf77yM5Lit5Zu95peg6ZSh77yI5Lym5pWm77yJ55WZ5a2m5Lq6?=
        =?UTF-8?B?5ZGY5Yib5paw5Yib5Lia5oGz6LCI5Lya77yM5Lym5pWm5Zu96ZmF5Y2O6K+t55S15b2x6IqC44CRIE5v?=
        =?UTF-8?B?LiAwMTIuZG9jeA==?="
Content-Disposition: attachment; 
        filename="=?UTF-8?B?44CQQ1NTQS1DQU3jgJHjgJDkuJbnlYzmmK/miYDmnIDmo5LnmoTlpKflrabigJTlrZnkuIDluIY=?=
        =?UTF-8?B?55qE5Lyg5aWH5pWF5LqL77yMMTIuNiBza3lsaW5l5bCx5Lia5oyH5a+86K6y5bqn77yM6aaW5bGKQ2Ft?=
        =?UTF-8?B?YnJpZGdlIENTU0Hnr67nkIPotZsoM3ZzMyzljZXmjJHvvIzkuInliIYp5Y+KQ1NTQeWNjuS6uuevrg==?=
        =?UTF-8?B?55CD6Zif6YCJ5ouU5oub5Yuf77yMMjAxNC4xMi4wNui2s+eQg+i/veaipuS6uu+8jFRFRHhA5YmR5qGl?=
        =?UTF-8?B?5aSn5a2m5ryU6K6y5ZiJ5a6+5oub5Yuf77yM5Lit5Zu95peg6ZSh77yI5Lym5pWm77yJ55WZ5a2m5Lq6?=
        =?UTF-8?B?5ZGY5Yib5paw5Yib5Lia5oGz6LCI5Lya77yM5Lym5pWm5Zu96ZmF5Y2O6K+t55S15b2x6IqC44CRIE5v?=
        =?UTF-8?B?LiAwMTIuZG9jeA==?="

this provokes an error from MHonARC:

ERROR: Unable to rename "/var/lib/sympa/arc/[email protected]/2014-12/msg00001/mHjQknQe9u." to "/var/lib/sympa/arc/[email protected]/2014-12/msg00001/___CSSA-CAM_______________________________________________________________12.6_skyline___________________________Cambridge_CSSA_________(3vs3,_______________)___CSSA______________________________2014.12.06__________________TEDx@____________________________________________________________________________________________________________________________No._012.docx": File name too long

A bit of digging around revealed that this was down to the following setting in mhonarc-ressources.tt2

<MIMEARGS>
m2h_external::filter; subdir usename 
</MIMEARGS>

If I remove that the archiving still seems to work correctly and I end up with shorter / more useful filenames. In particular it seems to work better if a message contains several attachments with the same name.

Is there a particular reason that I shouldn't remove subdir usename from MIMEARGS?

@ikedas ikedas added the bug label Jul 23, 2019
@ikedas
Copy link
Member

ikedas commented Aug 1, 2019

I guess there are no harm removing options from MIMEARGS.

@dpc22
Copy link
Contributor Author

dpc22 commented Aug 1, 2019

Thanks, that is what I concluded.

The filenames are occasionally a bit odd, but no different from our existing list archives on Mailman.

@ikedas ikedas added this to the 6.2.46 milestone Aug 9, 2019
@ikedas ikedas self-assigned this Aug 9, 2019
ikedas added a commit that referenced this issue Aug 16, 2019
Changes in mhonarc-ressources.tt2 (#699)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants