>> Thank you for your hints and sorry for the late followup. busy and stuff.
>> thank you for your suggestions, I was aware of the csr-option but wanted
>> to avoid this, since it does not well automate with certbot.
>
> Sine "--csr" is a certbot option I am surprised to hear you say that
> "it
>
>> On Apr 6, 2017, at 5:02 PM, G. Schlisio <g.schli...@dukun.de> wrote:
>>
>> I wonder if it is possible to have one cert per port postfix is serving
>> on, eg one for 25 and one for 587.
>
> Yes.
>
>master.cf:
> submissio
Hi all,
I wonder if it is possible to have one cert per port postfix is serving
on, eg one for 25 and one for 587.
Background of this:
for user interaction (mainly on port 587) I would like to use my signed
letsencrypt cert which changes fairly often.
For interaction of servers I would like to
> I managed to find where this is happening. It is not in glibc but in
> systemd.
>
> If your /etc/nsswitch.conf has something like this:
>
> passwd: compat mymachines systemd
>
> then the routines that are being used are systemd ones.
>
> The checks being done are here in the function
>
> I tried that on archlinux. The above program still produces EINVAL for
> login names between 32 and 255 inclusive.
>
> _SC_LOGIN_NAME_MAX is 256 on that platform.
>
> John
>
hi,
earlier i tried with literal "AA", which was probably not what you
meant.
it produced a "not found".
using
> Georg
>
> I don't think there is enough evidence at the moment to say with
> certainty that any change in glibc has introduced the problem, since you
> were using that for a while now without seeing issues.
>
> I'd still be interested in knowing what output the test program gives on
> the
Am 24.12.2016 um 08:40 schrieb John Fawcett:
> On 12/24/2016 01:19 AM, Wietse Venema wrote:
>> John Fawcett:
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL
> Georg
>
> Replying to my own post: on re-reading the specification, it looks clear
>
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL in /*result/. In case of error,
> It was worth checking the obvious to exclude it.
>
> I suspect that one of the system libraries used by the .forward
> mechanism has been impacted by your upgrade.
>
> If you don't need to use .forward files you might try setting
>
> forward_path =
>
> in main.cf and restart postfix. If that
Am 23.12.2016 um 15:11 schrieb John Fawcett:
> On 12/23/2016 01:56 PM, G. Schlisio wrote:
>>> Couldn't find the postconf -n output at that link
>> sorry, correct link for postconf -n: http://termbin.com/w509
>
> It doesn't look like "local" is even attempting to
> Couldn't find the postconf -n output at that link
sorry, correct link for postconf -n: http://termbin.com/w509
> Hi Georg
>
> for reporting problems you can refer to
> http://www.postfix.org/DEBUG_README.html#mail if you have not already
> seen it.
>
> For the configuration, command output from *
> *
>
> *postconf -n*
>
> *postconf -Mf*
>
> is a good starting point. Most people post it to the list,
>
> Georg
>
> probably the best thing is to compare your previous configuration to the
> new one and see what changed.
>
> For help with your current configuration, you should post it.
>
> John
hi john,
thank you for your suggestion. as i tried to indicate with "no changes
in mail config"
Dear list,
We have a mail server with postfix and dovecot on Archlinux where we
have mail
addresses with local unix accounts (authenticated by pam) and without
unix accounts (dovecot passwd-file authentication). The problem only
affects those non-unix account mail addresses. (There are also
14 matches
Mail list logo
