Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

could you support /etc/mailname? #974

Closed
aradici opened this issue Nov 30, 2017 · 5 comments
Closed

could you support /etc/mailname? #974

aradici opened this issue Nov 30, 2017 · 5 comments
Assignees
Labels
has:patch Patch attached type:enhancement Feature Request

Comments

@aradici
Copy link
Contributor

aradici commented Nov 30, 2017

We talked about this in the chat, given that /etc/mailname is present on both Debian and Ubuntu, I was wondering if you could support /etc/mailname to determine the Fqdn.

I wrote this patch for the latest neomutt stable:
https://anonscm.debian.org/cgit/pkg-mutt/neomutt.git/tree/debian/patches/debian-specific/882690-use_fqdn_from_etc_mailname.patch

But probably this one for the latest mut stable might apply cleanly at this point, given that you sync often to mutt head:
https://anonscm.debian.org/cgit/pkg-mutt/mutt.git/tree/debian/patches/debian-specific/882690-use_fqdn_from_etc_mailname.patch

Or you could write any similar variation and I'll happily drop mine!

If you are interested I opened a similar bug to mutt upstream:
https://dev.mutt.org/trac/ticket/3980

@flatcap
Copy link
Member

flatcap commented Nov 30, 2017

Note to self (or anyone who wants an easy task):

Debian looks for /etc/mailname
OpenBSD looks for /etc/mail/mailname (reference)

libmutt has functions mutt_file_read_keyword() or mutt_file_read_line() which may be of use.

Rather than configure which one to read, it might be simpler to look for both.

gahr added a commit that referenced this issue Dec 1, 2017
Currently, we support reading from /etc/mailname and /etc/mail/mailname.
Adding support for more files is trivial. Reading these files is only
done if NeoMutt was configured without the --with-domain option.

Issue #974
@gahr gahr self-assigned this Dec 1, 2017
gahr added a commit that referenced this issue Dec 1, 2017
@aradici
Copy link
Contributor Author

aradici commented Dec 5, 2017

the proposed fix in the mutt upstream code is to do
set hostname="`cat /etc/mailname`" in /etc/Muttrc which could also make sense

@gahr
Copy link
Member

gahr commented Dec 5, 2017

Yes, although that would be something distro maintainers would need to do basing on where - if anywhere - that file is in a particular distribution.

So, it’s either we support some common use cases or say “not our business” and let distros - or end users - deal with that.

I don’t have a strong opinion. My mild opinion is we should go either the full-way or no-way-at-all. The full-way way would be to try as hard as we can to figure out the hostname, so adding support for mailname files would bring us closer to that.

The no-way-at-all way would be to drop utsname, getaddrinfo, ndis lookup etc altogether and only support the hostname variable.

I’m all ears ;)

@flatcap
Copy link
Member

flatcap commented Dec 6, 2017

I'm not too worried about adding this, for now.
We already have a precedent: nntp reads /etc/nntpserver

Is /etc/mailname always going to be the case?
Or should the code reference SYSCONFDIR/mailname?
/usr/local/etc/mailname for example?

@gahr
Copy link
Member

gahr commented Dec 6, 2017

Neither Debian nor the smtpd reference you mentioned talk about sysconfdir.. I think we should be fine with the patch as is.

flatcap pushed a commit that referenced this issue Dec 7, 2017
Currently, we support reading from /etc/mailname and /etc/mail/mailname.
Adding support for more files is trivial. Reading these files is only
done if NeoMutt was configured without the --with-domain option.

Issue #974
flatcap pushed a commit that referenced this issue Dec 7, 2017
Currently, we support reading from /etc/mailname and /etc/mail/mailname.
Adding support for more files is trivial. Reading these files is only
done if NeoMutt was configured without the --with-domain option.

Issue #974
@flatcap flatcap closed this as completed Dec 7, 2017
flatcap pushed a commit that referenced this issue Dec 8, 2017
Currently, we support reading from /etc/mailname and /etc/mail/mailname.
Adding support for more files is trivial. Reading these files is only
done if NeoMutt was configured without the --with-domain option.

Issue #974
nabijaczleweli pushed a commit to nabijaczleweli/neomutt.deb that referenced this issue Mar 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has:patch Patch attached type:enhancement Feature Request
Projects
None yet
Development

No branches or pull requests

3 participants