[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2 nits about mailabbrev

From: Kevin Rodgers
Subject: Re: 2 nits about mailabbrev
Date: Mon, 27 Sep 2004 17:13:46 -0600
User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv: Gecko/20020406 Netscape6/6.2.2

John Owens wrote:
> Kevin Rodgers <ihs_4664 <at> yahoo.com> writes:
>>Yes, but don't those other MUAs that grok .alias also generate a
>>non-compliant To: header?  And isn't the solution to that problem to
>>explicitly include the necessary quotes:
>>alias gwbush "\"George W. Bush\" <president <at> whitehouse.gov>"
> The other MUAs probably do it wrong. However, in my informal experiments
> with different MUAs some time ago (I think I tried VM, /bin/mail, and
> Wanderlust), the most widely supported format among MUAs was
> alias gwbush "George W. Bush <address@hidden>"
> Other formats had errors in different MUAs. I do encourage others to
> try different MUAs to check. But my conclusion at the time was
> certainly that I should leave my .alias in the format above, since it
> was the most widely supported.

FWIW, I use VM + smtpmail.el + mailabbrev.el

> The issue at hand, I think, is "what should mailabbrev do?" It seems to
> me that no matter what other MUAs might do, mailabbrev should take the
> common .alias format as an input and output a RFC-822 compliant string
> if it can. I think that's better than the current behavior.


>>Doesn't this code from sendmail-send-it do the right thing?
> It may, although I'm using mailabbrev without sendmail-send-it, so it
> doesn't help me. I think putting it in both places would not hurt; some
> people use mailabbrev without sendmail-send-it, some people use
> sendmail-send-it without mailabbrev, and they could certainly be
> mutually compatible. It would be possible to control mailabbrev's
> munging with a variable and set it as nil by default, but since my
> proposed change doesn't hurt anything and only makes it more correct
> (I hope), I don't think this is necessary.

If we change mailabbrev.el, then mailalias.el should be kept in sync.

If we change sendmail.el, then smtpmail.el, feedmail.el, and mailpost.el
should be kept in sync.  I think that's the proper place to fix the
problem, since it's not strictly an alias problem: the same address
could be entered manually, and there are other encoding issues with
addresses that Emacs should handle (e.g. non-ASCII characters).

It'd be nice to eliminate some of the code duplication in those files.
If the snippet from sendmail-send-it works, it could just be
encapsulated as a new function (send-mail-encode-rfc822-recipient or
something) that the other *mail.el files could call as well.

Kevin Rodgers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]