Brian grabbed a keyboard and wrote:
> On Fri 01 Mar 2013 at 00:35:35 -0700, Bob Proulx wrote:
>
>> David Guntner wrote:
>>> Anyway, the recipe is dirt simple.
>>> ...
>>> # Duplicate Suppression.
>>> :0Whc: $MAILDIR/.msgid.cache.lock
>>> | $FORMAIL -D 8192 $MAILDIR/.msgid.cache
>>>
>>> # Take out the Trash.
>>> :0 a:
>>> /dev/null
>>>
>>> That's all there is to it. The formail program is used to grab the
>>> Message-ID of the incoming message. Even if it is sent To: one address
>>> and CC: another, both "copies" will have the same Message-ID. When the
>>> first one comes in, it stores that ID in the $MAILDIR/.msgid.cache file
>>> after first comparing the message to see if that ID has already been
>>> stored there. If not, then it stores the ID and returns a FALSE so that
>>> the second part ("take out the trash") won't process. If the Message-ID
>>> already *has* been stored in the cache file, then it returns a TRUE and
>>> the second part then dumps the message into /dev/null.
>>
>> If it works for you then great. But this is not without problems for
>> others.
>
> I send you mail with a job application. You accidentally delete it and
> request I provide it again. I enter my sent mail folder and use the
> bounce facility in Mutt to resend the mail. The procmail rule deletes
> it. At some point I may start to wonder why I never made the short-list.
>
> "Be strict in what you send and generous in what you receive" is still a
> good maxim to follow.
I agree. And when I'm setting up a mail *server* (which typically
services the needs of multiple users, even if I'm most likely going to
be the only one using it), I follow that to a reasonable degree (I do
set up some fairly conservative DNSBL lookups for the worst spam
offending sources). But when I (or any other person, for that matter)
am setting up my personal mail handling, I'm free to be as strict on
what I receive as I care to.
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.
I can't speak for other people who use Mutt any more than you can, but I
would never consider using the bounce function to resend a message that
*I* sent. If I pull it out of the sent message folder, I use forward.
Because bounce is typically used for resending a message that was sent
*to* you, not *by* you, making it look to the end recipient (that you're
bouncing it to) as though the message came from the person who sent it
to you.
And if you really want to clutch at straws, if I *were* the employer
that you're trying to contact, chances are the E-Mail address you're
using gets *lots* of mail. That above rule caps the cache file at 8K
("-D 8192"). Old stuff drops off as new stuff comes in. When storing
Message-ID strings, 8K isn't particularly large; the odds are that by
the time you resent me the message using the ill-advised (IMO) bounce
function instead of forward, your original ID would probably have
already fallen out. And if it's something that I (or anyone else who
dislikes receiving multiple copies of a message and as such are using a
rule such as the above) decided to worry about because I think I'm
losing mail, I can always decrease the cache size to 4K or whatever.
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. :-)
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.
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. :-)
--Dave
signature.asc
Description: OpenPGP digital signature
