Working around RFC2045 non-compliance

View: New views
4 Messages — Rating Filter:   Alert me  

Working around RFC2045 non-compliance

by Pete Ford-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

One of my clients has a regular correspondent who is using Outlook 12 to send
him messages. These usually carry a Word doc attachment, and Outlook is being
silly about it's MIME boundaries, as expected. The upshot is, of course, that
the word doc is not readable to the client...

I know that I can, in principle, hack the source code to eliminate the error
messages for this sort of thing, but the associated risks are too great for me
to accept.

I wondered if there is an alternative: is it possible to catch incoming messages
before they pass through this format check? For example, could I make a
python-filter which might be able to scan messages for signs of RFC2045-ignorant
MIME boundaries and either fix them up, or at least copy the message to a file
so I can do some further investigation of it?

I'm a bit unsure about where things like python-filter fit into the order of
processing (as you can see...)

I suppose the alternative would be to put some kind of proxy in front of the
real mail server to do such filtering - bit of a sledgehammer/nut solution that.

Cheers
Pete

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
courier-users mailing list
courier-users@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: Working around RFC2045 non-compliance

by Jeff-280 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Pete Ford <pford@...> wrote on 2008-Sep-19:

> One of my clients has a regular correspondent who is using Outlook 12 to send
> him messages. These usually carry a Word doc attachment, and Outlook is being
> silly about it's MIME boundaries, as expected. The upshot is, of course, that
> the word doc is not readable to the client...
>
> I know that I can, in principle, hack the source code to eliminate the error
> messages for this sort of thing, but the associated risks are too great for me
> to accept.
>
> I wondered if there is an alternative:

I think you want

  opt BOFHBADMIME=accept

in the 'bofh' file in courier's 'etc' directory.

Check out 'man courier' and then search for BOFHBADMIME to see what your
options are.

HTH

Jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
courier-users mailing list
courier-users@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: Working around RFC2045 non-compliance

by Pete Ford-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jeff,

Thanks for that hint - I had a nagging feeling that there was a BOFH setting,
but the documentation I looked in (FAQ, for example) did not mention it. I will
see if that improves things.

As a follow up: given that these messages have been sanitized by Courier, is
there a tool or a process to reconstruct the original message from the sanitized
version?

Cheers

Pete

Jeff wrote:

> Pete Ford <pford@...> wrote on 2008-Sep-19:
>> One of my clients has a regular correspondent who is using Outlook 12 to send
>> him messages. These usually carry a Word doc attachment, and Outlook is being
>> silly about it's MIME boundaries, as expected. The upshot is, of course, that
>> the word doc is not readable to the client...
>>
>> I know that I can, in principle, hack the source code to eliminate the error
>> messages for this sort of thing, but the associated risks are too great for me
>> to accept.
>>
>> I wondered if there is an alternative:
>
> I think you want
>
>   opt BOFHBADMIME=accept
>
> in the 'bofh' file in courier's 'etc' directory.
>
> Check out 'man courier' and then search for BOFHBADMIME to see what your
> options are.
>
> HTH
>
> Jeff
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> courier-users mailing list
> courier-users@...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
courier-users mailing list
courier-users@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: Working around RFC2045 non-compliance

by Jeff-280 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Pete Ford <pford@...> wrote on 2008-Sep-19:
> As a follow up: given that these messages have been sanitized by Courier, is
> there a tool or a process to reconstruct the original message from the sanitized
> version?

Courier's default behavior is to "wrap" the original message into a new
attachment.  So you should be able to "open" the new attachment in your
email client and find the original attached file in there.

HTH

Jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
courier-users mailing list
courier-users@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
LightInTheBox - Buy quality products at wholesale price!