bug-mailfromd

Search for: Advanced

Re: [Bug-mailfromd] attachment filtering / removal

> 
> > >
> > > Can you advise on some best practice for rejecting messages having
> > > attachments with specific file extensions?
> > >
> 
> Use current_message[1] to get the descriptor of the message.  Use
> message_count_parts[2] to obtain the number of MIME parts in the
> message, and iterate over them.  For each part, obtain its descriptor
> using message_get_part[2], and inspect the value of
> "Content-Disposition" and "Content-Type" headers using
> message_find_header[3]
> function.  You might need to unfold[4] these values before using them.
> In order to get the attachment file name, refer to discussions of these
> headers in RFC 1806[5] and 1521[6], correspondingly.
> 
> This all should be done in prog eom.  Furthermore, notice that MIME
> parts can be nested, so that this process is inherently recursive:
> the function that iterates over message parts is supposed to call
> itself when it encounters a message part of type "multipart/*".  It
> would be wise to limit the recursion depth somehow.  Finally, it is
> obvious that the process might be quite resource-consuming: you might
> need to tune your stack size[7] in order to silent expansion warning
> messages.
> 
> [1] https://www.gnu.org.ua/software/mailfromd/manual/Current-Message-
> Functions.html
> [2] https://www.gnu.org.ua/software/mailfromd/manual/MIME-functions.html
> [3] https://www.gnu.org.ua/software/mailfromd/manual/Header-
> functions.html
> [4] https://www.gnu.org.ua/software/mailfromd/manual/Mail-header-
> functions.html
> [5] https://www.rfc-editor.org/rfc/rfc1806.html
> [6] https://www.rfc-editor.org/rfc/rfc1521
> [7] https://www.gnu.org.ua/software/mailfromd/manual/stacksize.html


Thanks again very much! Perfect blueprint for implementing. I guess eom is parsing the whole message not? I am currently experimenting with dkim in eom from the example. So I guess adding this is not giving me extra overhead? I have sometimes quite large attachments, so maybe good if I can try and limit parsing the whole message.

switch dkim_verify(current_message())

I was also thinking of maybe checking if clamav can just reject on file extensions. I already have that running.