Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#40823 - [s-nail] Add standard ttycharset to mail.rc

Attached to Project: Arch Linux
Opened by georg (fordprefect) - Thursday, 12 June 2014, 18:36 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 15 June 2014, 20:12 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


while sending emails from a deamon i encountered the problem, that deamons seam to have no locale set, so the mail containing utf8 characters was not send.
to prevent this i added:
set ttycharset=utf8
to /etc/mail.rc
I suggest adding it by default as i think this is a sane default and will help other people too

Additional info:
* done using s-nail 14.7-1

thanks for consideration
This task depends upon

Closed by  Gaetan Bisson (vesath)
Sunday, 15 June 2014, 20:12 GMT
Reason for closing:  Not a bug
Comment by Gaetan Bisson (vesath) - Thursday, 12 June 2014, 22:47 GMT
Sounds good.
Comment by Gaetan Bisson (vesath) - Thursday, 12 June 2014, 22:49 GMT
Hum, except we get our mail.rc from upstream. Would you care to take the issue up there?
Comment by georg (fordprefect) - Thursday, 12 June 2014, 22:54 GMT
ok, i'll do that and report back here.
Comment by Steffen Nurpmeso (sdaoden) - Friday, 13 June 2014, 21:01 GMT
Copied from s-nail-users@:

Hello again Georg, sorry for the delay,

|i am using s-nail as an archlinux user and i encountered a problem while
|sending a mail via script from a deamon.
|it turned out that this deamon had no locale set, so mail did not know
|about the charset to use.
|on further investigation i found your option 'ttycharset' and adding
|'set ttycharset=utf8' fixed this problem.
|i'd like to propose this as a standard setting here since i see utf8 as
|a widespread an commonly accepted encoding and thus this setting as a
|sane default.

i don't think that this is a good idea, not only because of what
Predrag said (who seems to be using a very old and super-buggy
version of S-nail and therefore also has a lot of other problems
to face).

But first of all i wondered how your daemon is capable to produce
messages in character sets other than what your locale a.k.a.
LC_ALL / LC_CTYPE [/ LANG] tells it. Or does the script which
then calls S-nail explicitly exports LC_ALL=C before doing so,
overriding the settings used by the daemon?
Unfortunately most daemon manuals i've seen assume an astonishing
level of general Unix environment knowledge, as if everybody would
be a paid full-time administrator / programmer who is familiar
with all the inter-dependencies.

And unfortunately S-nail seems to do so, too.
I've updated the template .rc file of S-nail (which ends up as
`/etc/mail.rc' on ArchLinux) a bit so that it now reads

# [OPTION] Outgoing messages are sent in ISO-8859-1 if all their characters
# are representable in it, otherwise in UTF-8.
# Note: it is highly advisable to read the section "Character sets" of the
# manual in order to understand all the possibilities that exist to fine-tune
# charset usage (variables also of interest: *ttycharset*, *charset-8bit*,
# *sendcharsets-else-ttycharset*; and of course we inherit the $LC_CTYPE /
# $LC_ALL / $LANG environment variables and react upon them)
set sendcharsets=iso-8859-1,utf-8

Note that setting *sendcharsets* should be the solution also for
you, i guess. Or doing something like

echo bla | LC_ALL=en_US.UTF-8 mailx -Aaccount -s sub RECEIVER

may do the trick in a standard way -- i think i'll also add an
according example to the manual.
[Addon: the manual section "Character sets" is already pretty detailed, too.]

I refrain from setting *ttycharset*, however, because in that case
it would be a hard override of the actual real locale environment,
which i guess would irritate even more users. E.g. it would break
my personal BSD (except Mac OS X) installations.
Even for the non-iconv(3) installations (which ArchLinux isn't one
of) we should not do so because different to the current fallback
default of *ttycharset* in this case, ISO-8859-1, UTF-8 is
a multibyte encoding which thus may generate decoding errors.
I think i'll make it a compile-time option nonetheless, because of
UTF-8-only environments, like musl-libc. So thanks for bringing
this up.

Ok for you?
Comment by Gaetan Bisson (vesath) - Sunday, 15 June 2014, 20:12 GMT
That sounds good.