implementing /etc/mailname

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Some possibly silly questions.  Policy §11.6 recommends:

	If your package needs to know what hostname to use on (for
	example) outgoing news and mail messages which are generated
	locally, you should use the file /etc/mailname. It will contain
	the portion after the username and @ (at) sign for email
	addresses of users on the machine (followed by a newline).

which allows

 - a single machine to have multiple fqdns (virtual hosts), the
   mail service being only one of them, or
 - mail to be taken care of by a different machine

Useful enough.  Unfortunately, implementing that policy requires
Debian-specific patches that are more invasive than the nicer "use
'editor' in place of 'vi'" kind of changes from policy 11.4.  Results:

 - a larger delta from upstream, usually; complexity in code that only
   applies to Debian;
 - other operating systems miss out on this feature;
 - mailname support does not benefit from upstream testing.

Can we do better?  Has there been work on cross-distro standardization
of something like /etc/mailname?  Barring that, would there be
interest in a (Debian-specific) Debian-specific getmailname() function
to be used instead of patches like

-     gethostname(default_email + len, sizeof(default_email) - len);
+
+     /* On Debian check /etc/mailname before using gethostname */
+     FILE *mailname = fopen("/etc/mailname", "r");
+     if (mailname && fgets(default_email + len,
+                       sizeof(default_email) - len, mailname)) {
+           int l = strlen(default_email + len);
+           if (default_email[len+l] == '\n')
+                 default_email[len+l] = 0;
+     }
+     else {
+           if (errno != ENOENT)
+                 warning("unable to read /etc/mailname: %s\n",
+                        strerror(errno));
+           gethostname(default_email + len,
+                     sizeof(default_email) - len);
+     }
+     if (mailname)
+           fclose(mailname);

?  To avoid slowing down app startup ("scripting performance") it
could be an inline function.