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
comple
On 12/23/2016 09:47 AM, G. Schlisio wrote:
> 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
>
> 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" th
On 12/23/2016 10:33 AM, G. Schlisio wrote:
>> 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
Thank you. But when I use
smtpd_end_of_data_restrictions =
check_sender_access static:INFO
I get,
postfix/smtpd[13668]: warning: unknown smtpd restriction: "INFO
postfix/smtpd[13668]: 12E9F6420F: reject: END-OF-MESSAGE from
host[x.x.x.x]: 451 4.3.5 Server configuration error; fro
not good:
3 phases :
1 --> the mail is for admin or CRM ? --> forward to admin or crm && return 0
2 --> the mail is crap --> delete it && return 0
3 --> none of the previous --> send to bdd by api rest call http
so the sendmail is not always the final decision ...
I feel that the originale r
> 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, bu
On 12/23/2016 12:34 PM, G. Schlisio wrote:
>> 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
> Couldn't find the postconf -n output at that link
sorry, correct link for postconf -n: http://termbin.com/w509
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 open the
mailbox_transport_maps file. That's a good indication that the config
file you
Obviously I am being thick but can someone explain why this does not
work as I would expect. Basically email addresses are not matching
against domain names in a hashed database:
$ postconf|grep "^parent_domain_matches_subdomains.*smtpd_access_maps"
>/dev/null && echo "domain.tld should match
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 open the
> mailbox_transport_maps
On 12/23/2016 03:13 PM, Dominic Raferd wrote:
> Obviously I am being thick but can someone explain why this does not
> work as I would expect. Basically email addresses are not matching
> against domain names in a hashed database:
>
> $ postconf|grep "^parent_domain_matches_subdomains.*smtpd_access
> On Tue, Dec 20, 2016 at 7:35 PM, Viktor Dukhovni
> wrote:
> >
> > > On Dec 20, 2016, at 12:53 AM, Burn Zero
> > > wrote:
> > >
> > > As you can see the orig_to parameter shows the original id to
> > > which the email was sent and the to= parameter explains the
> > > rewritten email id. I ca
On 23/12/2016 14:27, John Fawcett wrote:
On 12/23/2016 03:13 PM, Dominic Raferd wrote:
Obviously I am being thick but can someone explain why this does not
work as I would expect. Basically email addresses are not matching
against domain names in a hashed database:
$ postconf|grep "^parent_doma
On 12/23/2016 03:20 PM, G. Schlisio wrote:
> 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 att
> 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
On 12/23/2016 03:56 PM, G. Schlisio wrote:
>> 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
On 12/23/2016 03:34 PM, Dominic Raferd wrote:
> On 23/12/2016 14:27, John Fawcett wrote:
>> On 12/23/2016 03:13 PM, Dominic Raferd wrote:
>>> Obviously I am being thick but can someone explain why this does not
>>> work as I would expect. Basically email addresses are not matching
>>> against domai
On 21 Dec 2016, at 5:42, L.P.H. van Belle wrote:
Hello Noel,
Would you please stop say that im labeling.. im not.
Sorry im so bad in explaining things in english.
I just trying to explain something based on what i did read here:
http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostna
On 12/23/2016 05:29 PM, John Fawcett wrote:
> On 12/23/2016 03:34 PM, Dominic Raferd wrote:
>> On 23/12/2016 14:27, John Fawcett wrote:
>>> On 12/23/2016 03:13 PM, Dominic Raferd wrote:
Obviously I am being thick but can someone explain why this does not
work as I would expect. Basically
On 12/23/2016 04:29 PM, John Fawcett wrote:
> On 12/23/2016 03:56 PM, G. Schlisio wrote:
>>> 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 .fo
ignore the previous message it was sent in the wrong thread, apologies
for the noise.
> 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, an
On 12/23/2016 06:22 PM, G. Schlisio wrote:
>> 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 a
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 in /*result/. In case of error, an
> >> error number is returned, and NULL is stored in /*result/. "
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 in /*result/. In case of error, an
error number
27 matches
Mail list logo
