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,
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
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
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 attr_
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):
>
> 2015-
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 outgoingm
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 tex
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
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() f
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 :
Mats Luspa:
connect(16, {sa_family=AF_LOCAL, sun_p
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,
>
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,
"R_4\322w\5\231\277S\36\306\374\330\217\320$\306\242\247\26
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 :
Wietse Venema:
$ uname -a
Linux ubuntu1410 3.16.0-30-generi
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 consist
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]: 487714329
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
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 201
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
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:~# pos
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"? Post
Wietse Venema:
> Mats Luspa:
> > 2015-02-13T23:41:33+02:00 outgoingmail-2 postfix/smtp[10214]:
> > 61BDCBEF4: to=,
> > 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 SeLinu
Mats Luspa:
> 2015-02-13T23:41:33+02:00 outgoingmail-2 postfix/smtp[10214]:
> 61BDCBEF4: to=,
> 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 turning it off.
I have
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 = PATH=/bin:/usr/bin:/usr/lo
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 :
> 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
Mats Luspa:
>
> 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 do
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 bou
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
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: to
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=,
> 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 (bounce or trace
> service failure)
Hello!
Thank you for your advice. However it still not works. In this link
https://moln.irf.se/owncloud/public.php?service=files&t=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
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
mydes
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.sesm
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
* smtp
33 matches
Mail list logo
