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

[Geoff Thorpe]

Glad to hear someone is taking this up! :-)

As for the approach, I think if you do take the approach of letting 
"unmatched" emails through, you should perhaps mangle the subject or 
prepend some template text to the body of the email. Otherwise it's less 
clear that someone will send a polite note to the author, and I rather 
think people will just wonder why the list looks like it did before the 
filter was introduced. :-)

As for the inlining/attachment argument, I assume that what is needed is 
something that makes "wine-patches" have a more standardised 
look/feel/use, like "wine-cvs". I would have personally thought that 
attachments make more sense, because separating patches from text can be 
ambiguous and it's not as easy to send multiple patches (eg. when 
submitting two alternative patches?) Then again, I'm not the biggest 
contributor or tester to wine-patches, so my opinion doesn't count for 
squat. :-) At the other extreme, Alexandre's opinion counts more than 
anyone's, because of all people he's the one that needs the smoothest 
experience with the patches. So perhaps it'd make sense for him to make a 
call once the filter's ready to start breaking down and reconstructing 
emails in some templated format?

On October 9, 2003 06:00 pm, Dimitrie O. Paun wrote:
> On Thu, 9 Oct 2003, Shachar Shemesh wrote:
> > 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.
>
> file(1) is your friend. Mime types are completely unreliable,
> and I see no point into forcing people use specific extensions.

I rather think that you need a prudent mix of both to take a decent swipe 
at most mailers, both in terms of dismantling incoming mail and formating 
outgoing ones. You could simply hack a series of pattern-matching rules 
on *anything* that seems relevant, and evolve them as you go. This is 
provided (as I mentioned earlier) you change something in the email to 
make it obvious that it "matched no filter", that way people know who 
need's sorting out and also when it might be appropriate to adjust the 
filter's logic.

> > 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?
>
> No, it doesn't. I can't easily reply to a message with an attachemnt,
> in that the attachemtn is not being quoated in the reply. Not Good
> (TM). I see no point in having such a filter if we don't do inlining,
> really.

Really? You're using pine I guess, from those headers. I would have 
thought this would have worked if the mime types were generated 
consistently and the MUA configured. But before we start debating as 
style police, is a choice even necessary? If there's going to be a mail 
filter able to do style-police on all mail-traffic, what is to stop it 
being able to generate more than one possible output? I don't know what 
the list server is, but it should be possible to have different 
preferences. Then again, if the filter takes place prior to mail-list 
processing maybe just splitting the list into multiple "channels" makes 
more sense, where you default to one of them but can change it via the 
preferences/unsubscribe administration. BTW: this is exactly what happens 
for people wanting daily digests instead of individual postings.

> > I think they way people learn what to do is by receiving feedback.
> > This is a chance to automate the feedback mechanism.
>
> I wouldn't worry about it for now. Let's see what we get out of the
> filter first, I have a strong suspicion there will be _very_ few
> emails that would need 'bouncing'. At which point an email from a
> real person is more polite and a better feedback. If we keep having
> a problem, we can think of automating it, but until then it's a
> solution looking for a problem.

Perhaps. Bouncing is certainly a bad idea, because a mail-list (being 
archived and widely read) is exactly the kind of email address that gets 
picked up easily by a virus so I don't think they should ever emit 
rule-based bounces, we've seen what happens with those damned spam 
filters. Instead, either forward them on as-is but with some noticable 
"flag" added, or /dev/null it. In the latter case, you could get around 
the obvious objection by creating another mail-alias that follows the 
same rules as the list-server but responds to the sender with parsing 
results.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/