attaching or inlining? what to do when you're stuck with a stupid mail client???[A

Shachar Shemesh wine-devel at shemesh.biz
Thu Oct 9 16:49:01 CDT 2003


Dimitrie O. Paun wrote:

>On Thu, 9 Oct 2003, Shachar Shemesh wrote:
>
>  
>
>>I think I can do that. What I suggest:
>>Attachments must be either .diff or .patch. If you want, they can be bz2 
>>or gz compressed. Mime type is disregarded. Also, the mail must be 
>>non-HTML (or, at least, must have a text only component). Emails that 
>>don't qualify are bounced.
>>    
>>
>
>Yes, historically there are few such emails, so there will be few
>bounces.  Another way of looking at it is that since they are so rare, 
>we can just let them through without any processing, I'm sure someone 
>on the list will reply to it.
>
>I think this is better aproach: just don't do any processing on
>messages that are 'strange'.
>  
>
What about emails that don't carry any recognized attachment at all? 
What if someone sends their stuff as "mychanges.myformat", or even 
"mychanges"? I don't think we can afford to process them, as it may lead 
to strange results.

>>Emails that do qualify are checked. If the mime type is "text/plain", 
>>and the extension is .diff or .patch, the mail is passed through.
>>    
>>
>Well, I'd say that is the attachment looks like text (regardless of
>the mime type), simply inline the patch. Once again, an inline patch 
>is so much better, one can easily reply to it, etc.
>  
>
I don't think that's a good idea. I think "looks like text" is 
difficult. I don't know how Japanese resources look like, nor how 
Keyboard layouts in Spanish. I'd rather go with the file extension.

Also, my mailer quotes attachments with the correct mime type properly. 
Attachments are less likely to get garbled, and so are preferred by me. 
I understand why you don't like them, as many mailer give incorrect mime 
type that causes your mailer to handle them incorrectly. I think this 
filter will solve that problem.

Now, my main objection to inlining is not relevant here either. As the 
inlining is done by a filter, there is no risk of line wrapping. Still - 
I think people should be encouraged to send in the same format they 
usually receive.

How about this - I'll keep them as attachments. If we find out people 
can't reply to them, we'll change it? I'll also make sure that messages 
that have inline patches are passed as is, so that your favourite method 
will still be supported. Sounds good?

>>If the email has a different mime type, or is compressed, it will be 
>>extracted and uncompressed. If it has an HTML component, it will be 
>>stripped. It will then be remailed (this time passing the filter, as it 
>>is text only).
>>    
>>
>No need to strip anything. As I said above, let's simply ignore
>messages with more than one attachment. They are far and few in
>between, I don't think they are a problem.
>  
>
I think they way people learn what to do is by receiving feedback. This 
is a chance to automate the feedback mechanism.

I'm still waiting to hear from someone in charge of the mailing list 
that such a filter will be integrated if I write it.

          Shachar

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/





More information about the wine-devel mailing list