To/Cc address uniquification

To/Cc address uniquification

[Lars Magne Ingebrigtsen]

That should be a word.

A very common situation at work is that I've misconfigured the MTA on my
machine, so messages from me to

  To: cvs

is expanded by the MTA to

  To: cvs@beatriz.netfonds.no

instead of cvs@netfonds.no.  That, in itself, is OK, but then somebody
responds to it and somehow both cvs@beatriz.netfonds.no and
cvs@netfonds.no get in the To/Cc headers, and then everybody gets two of
everything and I have to edit the headers and AAARGH.

Now, sensible people might suggest that I just fix the configuration on
my MTA, but, man!  That's boring.

So I want some functionality in Message that would root out these
obvious duplicates.  But I want it to be general.

Here's what I envision:

(setq message-uniquifications
      '(("\\([^@]+\\)@netfonds.no" "\\1@.*\\.netfonds.no")
      ;; Meaning that if you have foo@netfonds.no in the recipient list,
      ;; then all instances of foo@.*.netfonds.no should be removed.
        ("bugzilla@" ".*")
      ;; Meaning that if bugzilla is in the recipient list, then remove
      ;; all the other addresses.
      ("\\([^@]+\\)@\\(.*\\)$" "\\1@.*\\.\\2")
      ;; This would be a general rule that most people might want...
      ))

Doesn't that sound slightly useful?

And there's the \1 literal string expansion thing again that we were
talking about earlier.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: To/Cc address uniquification

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Now, sensible people might suggest that I just fix the configuration
> on my MTA, but, man!  That's boring.

Perhaps you should write an MTA implemented in common lisp?

Re: To/Cc address uniquification

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That should be a word.

It's implemented now, anyway.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: To/Cc address uniquification

[Ted Zlatanov]

On Tue, 31 Aug 2010 00:31:41 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> That should be a word.
LMI> A very common situation at work is that I've misconfigured the MTA on my
LMI> machine, so messages from me to

LMI>   To: cvs

LMI> is expanded by the MTA to

LMI>   To: cvs@beatriz.netfonds.no

LMI> instead of cvs@netfonds.no.  That, in itself, is OK, but then somebody
LMI> responds to it and somehow both cvs@beatriz.netfonds.no and
LMI> cvs@netfonds.no get in the To/Cc headers, and then everybody gets two of
LMI> everything and I have to edit the headers and AAARGH.

You could start with message-hierarchical-addresses and make it more
general.

LMI> Here's what I envision:

LMI> (setq message-uniquifications
LMI>       '(("\\([^@]+\\)@netfonds.no" "\\1@.*\\.netfonds.no")
LMI>       ;; Meaning that if you have foo@netfonds.no in the recipient list,
LMI>       ;; then all instances of foo@.*.netfonds.no should be removed.
LMI>         ("bugzilla@" ".*")
LMI>       ;; Meaning that if bugzilla is in the recipient list, then remove
LMI>       ;; all the other addresses.
LMI>       ("\\([^@]+\\)@\\(.*\\)$" "\\1@.*\\.\\2")
LMI>       ;; This would be a general rule that most people might want...
LMI>       ))

LMI> Doesn't that sound slightly useful?

Yes, slightly.  I'd need it if I ever ran mail services again ;)

LMI> And there's the \1 literal string expansion thing again that we were
LMI> talking about earlier.

Yeah, that's the piece I'd love to see generically available.

Ted

Re: To/Cc address uniquification

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> You could start with message-hierarchical-addresses and make it more
> general.

In that particular case, yes...  but not in the bugzilla case.  I
think. 

> LMI> And there's the \1 literal string expansion thing again that we were
> LMI> talking about earlier.
>
> Yeah, that's the piece I'd love to see generically available.

I'd actually coded the thing (missing just a few bits), and then I
though "well, why not just use `replace-match'", so I did that instead.

It fails if you're using things like "\\." in the replacement case, so
perhaps I should just finish the implementation.  On the other hand,
perhaps `replace-match' should just be more sensible...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen