Brian grabbed a keyboard and wrote:
> On Sat 02 Mar 2013 at 09:20:14 -0800, David Guntner wrote:
> 
>> Brian grabbed a keyboard and wrote:
>>
>> And face it, the scenario you describe above is not one I (or a number
>> of other people) are likely to run into all that often.  Possible, sure.
>> Probable, not as much.
> 
> Email deletion is final and irrecoverable. I am not prepared to delete
> mail based on an optional email header. You are. That's all there is to
> it. :)

Yup. :-)

While the RFC does not outright *mandate* a Message-ID header, it does
strongly recommend it.  And face it, in this day and age, when was the
last time you saw a message which did NOT contain that header?  The
"risk" of such a header not being there is so low as to be effectively
nonexistent.  And even if it *is* missing, then I suspect the rule I'm
using would allow both copies to come through since it has nothing to
compare against.  So that's a pretty weak argument.

>> As with anything, use the mail processing rules which work for you.  I'm
>> clearly not the only person in the world who *really* doesn't like
>> getting duplicate copies of mailing list replies, or I wouldn't have
>> posted that (I only did so because someone was complaining about exactly
>> that problem).  And I, for one, am not going to give up the convenience
>> of the above rule on the off chance that a 1-in-1000 scenario such as
>> the one you describe might happen. :-)
> 
> That's fine. It's your mail.

Actually, I did realize one thing that can be done with the rule I use
to deal with someone who uses the "bounce" function to forward mail from
their Sent folder to send it again for some reason.  Mutt will insert a
"Resent-Message-ID" header when the bounce function is used.  So by
adding a test to make sure that header is *not* present, it eliminates
the potential accidental deletion of such a resent message.

(Hey, I'm always rethinking things when a given scenario comes up, even
if I consider it to be of a fairly small probability factor - makes for
an interesting challenge sometimes. <grin>)

>> One thing that always amuses me about these types of discussions:  Every
>> once in a while, someone such as yourself will come along and say
>> something along the lines of, "Oh, you shouldn't do that because
>> scenario X might possibly happen."  But they never post an alternative,
>> which accomplishes the same goal without the perceived pitfall.
> 
> I tend to be amused when someone such as yourself expects me to solve a
> problem for them which can be solved by using the 'delete' key. You have
> the ideal solution for your needs. I have one for mine. Mine has the
> benefit of the judgement and decision making being made by a human being.

If *that* worried about it, it can always be directed into a folder that
you ("you" in the general sense, not "you" specifically) can review at
your leisure and hit the delete key to your heart's content. :-)

Yes, we all have a delete key.  And some of us get annoyed when we have
to use it repeatedly in situations where we really shouldn't have to.
The person I responded to clearly had a problem with "just hitting
delete," so I provided him with a solution that works.  You decided to
follow up by saying how you didn't like it and it can cause problems and
you like to just hit delete.  It's fine that you like that.  He didn't,
so I helped him out.  At no time did I say that You Must Use My
Solution. :-)

>> So, for those who think the above rule is some kind of evil incarnate
>> because Something Bad Might Happen - if you really want to talk someone
>> out of using such rules, provide an alternative that gives the same
>> functionality, without causing the Something Bad That Might Happen. :-)
> 
> This is a straitjacket requirement which brooks no alternative view.

It seems to me that "if you think it's that bad, how about an
alternative?" is *soliciting* an alternative view.  Simply saying,
"Don't do that, it's bad and I don't like it" is more of a straitjacket
since it provides no alternatives.

> What it says is "Give me an answer formulated in my terms". Sorry, you
> are seeking a technical solution to a social problem. It doesn't exist.

Actually, I am seeking no such thing.  What I *am* saying, however, is
that if you (again, in the general sense, not necessarily specifically
you) are going to come at someone with a "that solution is no good for
reason X," then it's only polite to provide an alternative (or a pointer
to where one might be found).  Hacker's Ethic, if nothing else. :-)

I've worked at places where the attitude of management was along the
lines of, "If you're going to come to me with a complaint about the way
something is being done, provide a possible solution.  Otherwise I don't
want to hear from you about it."  I happen to mostly agree with that
philosophy.  If someone is going to decide that they want to "complain"
(for lack of a better word) about a system I use to handle a given
situation, then they should also provide an alternative for
consideration and explain why it's better.  Otherwise, the "complaint"
really doesn't hold much weight.

So, if you really think I'm going to break something horribly to the
point where you've just got to tell me about it, then help provide a
solution that doesn't break whatever it is you think I'm going to break,
or at least a clue pointing to one.  You (yea, in this case you) seem to
have the opinion that mine is a horrible solution and I shouldn't be
sharing it with others who have a similar situation that they'd like to
handle.

Anyway, that's as much as I'm going to dwell on this issue; I have no
desire to drag it out into a long debate. :-)  If you have a reply, I'll
read it, but don't be surprised if there's no reply.  No offense is
intended; I just don't see that anything more can be derived from
further debate regarding it.

Handling mail is the personal prerogative of the one receiving it.  We
all have our ways of dealing with problem messages and so on; that's
part of the beauty of it.  But I'm still a Hacker's Ethic kind of guy
even in this day and age; if someone is having a problem that I've got a
solution for, I'm going to offer it to help.  It's up to them whether or
not they wish to implement it.  And when someone else offers up a
suggestion, I generally don't nay-say it unless I'm going to offer at
least an idea or two as to possible other ways that might or might not
be better.

So that's my $.02, and I'm done with the subject. :-)  Have a great weekend!

                  --Dave


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to