On Thu, 9 Oct 2003, Shachar Shemesh wrote: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.
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'.
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.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.
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?
I think they way people learn what to do is by receiving feedback. This is a chance to automate the feedback mechanism.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'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/
