Hello!
I've now added your logging code.
That code confirms that it's problems to read socket according to
logging below (inside mail_command_client is my own logging added to
confirm that I used the correct binary. Thank you for your efforts
again):
2015-02-15T17:51:31+02:00
Mats Luspa:
Hello!
I've now added your logging code.
That code confirms that it's problems to read socket according to
logging below (inside mail_command_client is my own logging added to
confirm that I used the correct binary. Thank you for your efforts
again):
On Sun, Feb 15, 2015 at 02:08:58PM -0500, Wietse Venema wrote:
Excellent. We narrowed down the problem to the VSTREAM_GETC() call,
established why the call failed, and I added logging in so that
this will be easier to diagnose in the future.
Should there be an explicit flush after the
Viktor Dukhovni:
On Sun, Feb 15, 2015 at 02:08:58PM -0500, Wietse Venema wrote:
Excellent. We narrowed down the problem to the VSTREAM_GETC() call,
established why the call failed, and I added logging in so that
this will be easier to diagnose in the future.
Should there be an explicit
On Sun, Feb 15, 2015 at 03:44:45PM -0500, Wietse Venema wrote:
Viktor Dukhovni:
On Sun, Feb 15, 2015 at 02:08:58PM -0500, Wietse Venema wrote:
Excellent. We narrowed down the problem to the VSTREAM_GETC() call,
established why the call failed, and I added logging in so that
this
Viktor Dukhovni:
On Sun, Feb 15, 2015 at 03:44:45PM -0500, Wietse Venema wrote:
Viktor Dukhovni:
On Sun, Feb 15, 2015 at 02:08:58PM -0500, Wietse Venema wrote:
Excellent. We narrowed down the problem to the VSTREAM_GETC() call,
established why the call failed, and I added
Thanks for the smtp -v/relay -v logging. Your logging confirms
that there is a bogus error talking to your bounce daemon.
Although Postfix detects the bogus error, unfortunately it produces
no informative logging for this particular error.
Questions:
- What is the output from uname -a? Postfix
Mats Luspa:
Hello!
Thank you for the exhausting explanation of the problem.
Here you got the requested information about the system:
root@outgoingmail-2:~# uname -a
Linux outgoingmail-2 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15
22:27:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
What
Hello!
Thank you for the exhausting explanation of the problem.
Here you got the requested information about the system:
root@outgoingmail-2:~# uname -a
Linux outgoingmail-2 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15
22:27:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@outgoingmail-2:~#
Wietse Venema:
Mats Luspa:
Hello!
Thank you for the exhausting explanation of the problem.
Here you got the requested information about the system:
root@outgoingmail-2:~# uname -a
Linux outgoingmail-2 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15
22:27:29 UTC 2014 x86_64 x86_64
Wietse Venema:
$ uname -a
Linux ubuntu1410 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:06:37 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
On this system, Postfix 2.11.1 logging shows that the bounce service
works as expected:
Feb 14 14:33:21 ubuntu1410 postfix/smtp[1383]: 487714329E:
On Sat, Feb 14, 2015 at 09:17:50PM +, Viktor Dukhovni wrote:
transport:
debu...@example.net debug:[127.0.0.1]:52
Send a single message to debu...@example.com, and post the resulting
trace file, which will be in the Postfix queue directory.
And, unlike me, be consistent
On Sat, Feb 14, 2015 at 03:30:45PM -0500, Wietse Venema wrote:
In conclusion, whatever the problem is, it is not in Postfix. My
test shows that it works fine in a non-container environment on what
should basically be the same kernel as what you use.
An strace of an smtp(8) delivery agent
Ok, thanks for your engagement in this topic. Maybe there can be a
problem with the host kernel also.
I will test to install this as an Docker on the same host machine and
see what happens.
/Regards Mats
Quoting Wietse Venema wie...@porcupine.org:
Wietse Venema:
$ uname -a
Linux
Mats Luspa:
connect(16, {sa_family=AF_LOCAL, sun_path=private/bounce}, 110) = 0
poll([{fd=16, events=POLLOUT}], 1, 360) = 1 ([{fd=16, revents=POLLOUT}])
write(16, nrequest\\0flags\\0queue_id\00067C9..., 469) = 469
poll([{fd=16, events=POLLIN}], 1, 360) = 1 ([{fd=16,
Yes, apparmor is used. But I'm not an expert in configuring apparmor.
But maybe something there is preventing the linux-container to read
some part of the file system that affects postfix.
I must check it.
/Mats
Quoting Wietse Venema wie...@porcupine.org:
Mats Luspa:
connect(16,
Hello!
Thanks for your suggestion. It seems to be some Permission denies in
the trace-file that comes below:
--
read(15, \27\3\3\0\340, 5)= 5
read(15,
Mats Luspa:
Yes, apparmor is used. But I'm not an expert in configuring apparmor.
But maybe something there is preventing the linux-container to read
some part of the file system that affects postfix.
I must check it.
Meanwhile, I have added logging to the mail_command_client()
On Sat, Feb 14, 2015 at 11:43:43PM +0100, Mats Luspa wrote:
Thanks for your suggestion. It seems to be some Permission denies in the
trace-file that comes below:
socket(PF_LOCAL, SOCK_STREAM, 0)= 16
fcntl(16, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(16, F_SETFL,
It can also be a bug in the kernel according to this post:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1390223
It's the same kind of behaviour and Ubuntu utopic (and event postfix)
is mentioned. I'm running the same version of kernel on the host
server which is mentioned in the
Am 13.02.2015 um 15:50 schrieb Mats Luspa:
I have configured an outgoing server that relays one domain to a
smtp-host and the rest of the addresses to the internet.
I'm using the transport_maps-option and have no value on relayhost.
The transport-map has the following information:
irf.se
On Fri, Feb 13, 2015 at 03:50:14PM +0100, Mats Luspa wrote:
I'm using the transport_maps-option and have no value on relayhost.
The transport-map has the following information:
irf.sesmtp:[mail.irf.se]:X
* smtp:
It generally makes more sense to simply set
Hello!
I have configured an outgoing server that relays one domain to a
smtp-host and the rest of the addresses to the internet.
I'm using the transport_maps-option and have no value on relayhost.
The transport-map has the following information:
irf.sesmtp:[mail.irf.se]:X
*
On Fri, Feb 13, 2015 at 05:35:34PM +0100, Mats Luspa wrote:
2015-02-13T16:31:52+02:00 outgoingmail-2 postfix/smtp[7438]:
EF63DBD1E: to=testarenadresssomintefi...@telia.com,
relay=mail.telia.com[62.20.233.128]:25, delay=5.4,
delays=0.01/0.01/0.31/5.1, dsn=4.3.0, status=deferred
Hello!
Thank you for your advice. However it still not works. In this link
https://moln.irf.se/owncloud/public.php?service=filest=a998ef1f04eee014ad3de67a83b4d45b I have the conf-parameters that I set and below there is some text from the log-file where you can see that it ends in the deferred
Hello again!
This is very strange. When I automatically trace the bounce process
according to the documentation here:
http://www.postfix.org/DEBUG_README.html#logging it works with the
bouncing.
The log file says:
2015-02-13T21:27:48+02:00 outgoingmail-2 postfix/smtp[9408]:
E430FBE20:
Hello!
Ok, here comes the info. I hope it will be useful:
---postconf -n-
alias_database =
alias_maps =
append_dot_mydomain = yes
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
debugger_command =
Mats,
show config and log as requested and tell your goal(s) and you will be helped.
No config and log - no help.
p@rick
* Mats Luspa ma...@irf.se:
Hello!
Thanks for the reply.
I've now looked at the log files and I think this problem has been
from beginning of this server because I
Mats Luspa:
2015-02-13T23:41:33+02:00 outgoingmail-2 postfix/smtp[10214]:
61BDCBEF4: to=nonexistingm...@telia.com,
relay=mail.telia.com[62.20.233.128]:25, delay=5.4,
delays=0.19/0.01/0.15/5.1, dsn=4.3.0, status=deferred (bounce or trace
service failure)
Are you using SeLinux? Try
Hello!
Thanks for the reply.
I've now looked at the log files and I think this problem has been
from beginning of this server because I started it a few days ago.
Everything work fine when I send to addresses that exists. The problem
is that when I send to addresses that don't exists the
Mats Luspa:
Hello again!
This is very strange. When I automatically trace the bounce process
according to the documentation here:
http://www.postfix.org/DEBUG_README.html#logging it works with the
bouncing.
The log file says:
I wrote most of Postfix, and I will speak in simple
Wietse Venema:
Mats Luspa:
2015-02-13T23:41:33+02:00 outgoingmail-2 postfix/smtp[10214]:
61BDCBEF4: to=nonexistingm...@telia.com,
relay=mail.telia.com[62.20.233.128]:25, delay=5.4,
delays=0.19/0.01/0.15/5.1, dsn=4.3.0, status=deferred (bounce or trace
service failure)
Are you
32 matches
Mail list logo
