On Jun 30, 2019, at 20:42, Viktor Dukhovni wrote:
>> On Jun 30, 2019, at 8:14 PM, Doug Hardie wrote:
>>
>>> By default, the Postfix SMTP server invokes the proxymap
>>> service for local user lookup, because the default
>>> local_recipient_maps setting looks like this:
>>>
>>> local_recipie
> On Jun 30, 2019, at 8:14 PM, Doug Hardie wrote:
>
>> By default, the Postfix SMTP server invokes the proxymap
>> service for local user lookup, because the default
>> local_recipient_maps setting looks like this:
>>
>> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
>>
>> Try, a
> On Jun 30, 2019, at 19:22, Wietse Venema wrote:
>
> Doug Hardie:
>> This is a small server with a few users that are all local. There
>> are several domain names that point to this server, but all of
>> them are just aliases for the main name. Received mail stops at
>> the rcpt to: line. T
On Sun, Jun 30, 2019 at 07:22:42PM -0400, Wietse Venema wrote:
> Doug Hardie:
> > This is a small server with a few users that are all local. There
> > are several domain names that point to this server, but all of
> > them are just aliases for the main name. Received mail stops at
> > the rcpt
Doug Hardie:
> This is a small server with a few users that are all local. There
> are several domain names that point to this server, but all of
> them are just aliases for the main name. Received mail stops at
> the rcpt to: line. There is no OK that occurs until shortly after
> 3 minutes from
Durga Prasad Malyala:
> Dear Wietse,
> I understand your point. I am doing the checking on all of these.
> iostat -xz shows nearly zero queue. w_await is in the low single
> digits. In maillog - I am getting the following errors.
>
> May 4 21:48:26 mail1 postfix/lmtp[32281]: 2830940E7A0B:
> to=,
Dear Wietse,
I understand your point. I am doing the checking on all of these.
iostat -xz shows nearly zero queue. w_await is in the low single
digits. In maillog - I am getting the following errors.
May 4 21:48:26 mail1 postfix/lmtp[32281]: 2830940E7A0B:
to=, relay=mail.xyz.com[private/dovecot-l
Durga Prasad Malyala:
> Thank you for your reply Wietse,
> You are my Yoda Jedi Master and I have greatest regard for you - Sincerely.
>
> Ive seen the above link earlier too and am at my wits end on this. I
> was wondering if there is any issue in LMTP handing mail over to
> dovecot.
I suppose t
Thank you for your reply Wietse,
You are my Yoda Jedi Master and I have greatest regard for you - Sincerely.
Ive seen the above link earlier too and am at my wits end on this. I
was wondering if there is any issue in LMTP handing mail over to
dovecot.
I've mailed this to the Dovecot group as well
Durga Prasad Malyala:
> Hello all,
> I am seeing consistent delays in writing to disk (my System redhat 7.2
> using GFS2 file system cluster)
>
> May 4 10:03:34 mail1 postfix/lmtp[11662]: E4EB75048C19:
> to=, relay=mail.xyz.com[private/dovecot-lmtp], delay=50,
> delays=0.02/0/0/50, dsn=2.0.0, st
On Fri, May 04, 2018 at 10:11:39AM +0530, Durga Prasad Malyala wrote:
> I am seeing consistent delays in writing to disk (my System redhat 7.2
> using GFS2 file system cluster)
I think 7.5 is current. Don't you want to upgrade?
The Red Hat support you pay for covers GFS2, Postfix and Dovecot.
Sounds like GFS2 operating normally.
Do you have any metrics on for the performance of the SAN during these events?
Quoting Durga Prasad Malyala :
Hello all,
I am seeing consistent delays in writing to disk (my System redhat 7.2
using GFS2 file system cluster)
May 4 10:03:34 mail1 postfix/l
Thank you for the honest response. I wish logs and a qshape were available
from my position, but alas, it is not my server, just my problem to solve.
I think the artificial rate delay is the throttling by messagelabs as an
antispam measure. Other outbound mail to various domains is sent and
receiv
> On Mar 24, 2016, at 11:34 PM, Aaron Routt wrote:
>
> The only logs I can access is the receipt-
You'll have to do better than that if you want help.
>
> Mar 19 19:00:13 mail-d1f9ab60 postfix/smtp[30442]: 3qQpd33djJzDywj:
> to=, relay=cluster1.us.[REDACTED].com[XXX.XX.XX.XXX]:25,
> conn_us
Thank you Viktor,
The only logs I can access is the receipt-
Mar 19 19:00:13 mail-d1f9ab60 postfix/smtp[30442]: 3qQpd33djJzDywj:
to=, relay=cluster1.us.[REDACTED].com[XXX.XX.XX.XXX]:25,
conn_use=66, delay=193766, delays=193728/38/0/0.1, dsn=2.0.0, status=sent
(250 ok 1458414013 qp 36488 server-16
> On Mar 24, 2016, at 10:40 PM, Aaron Routt wrote:
>
> delays=193728/38/0/0.1
Insufficient context. Post all the log entries for the queue-id
of the message that logged this combination of delays.
> http://www.postfix.org/postconf.5.html
> The format of the "delays=a/b/c/d" logging is as foll
I guess you are right. It looks like a second didn't go by, before
the message got on a queue. Is that right? I had previously
understood that in delays=a/b/c/d c is time elapsed from hand off from
client to queue.
Oct 29 16:56:39 pmx1 postfix/smtpd[7978]: EF7454059D:
client=unknown[192.168.0.2
Am 29.10.2013 22:08, schrieb Roman Gelfand:
> Sorry about that one. In fact, the other address was unreachable
> than. Please, keep in mind, it is the hand off from thunderbird to
> postfix I am interested in.
>
> Here is a good example.
>
> Oct 29 16:57:10 pmx1 postfix/smtp[8024]: EF7454059D
Sorry about that one. In fact, the other address was unreachable
than. Please, keep in mind, it is the hand off from thunderbird to
postfix I am interested in.
Here is a good example.
Oct 29 16:57:10 pmx1 postfix/smtp[8024]: EF7454059D:
to=,
relay=gmail-smtp-in.l.google.com[173.194.68.26]:25,
Am 29.10.2013 21:55, schrieb li...@rhsoft.net:
> Am 29.10.2013 21:46, schrieb Roman Gelfand:
>> How did you decide this is a network issue?
>
> Connection timed out?
[harry@srv-rhsoft:~]$ telnet 96.57.168.248 25
Trying 96.57.168.248...
telnet: connect to address 96.57.168.248: Connection timed
Am 29.10.2013 21:46, schrieb Roman Gelfand:
> How did you decide this is a network issue?
Connection timed out?
> How would you go about determining which router which switch?
it's hard to explain how to debug network issues
> On Tue, Oct 29, 2013 at 4:33 PM, li...@rhsoft.net wrote:
>>
>>
>>
Am 29.10.2013 21:25, schrieb Roman Gelfand:
> The client is thunderbird. Correct me if I am wrong, it appears it 40
> seconds for the client to hand over the email to the server? If so,
> where should I troubleshoot? are there maintenance
> tasks/configuration changes to improve this situation
How did you decide this is a network issue?
How would you go about determining which router which switch?
Thanks for your help.
On Tue, Oct 29, 2013 at 4:33 PM, li...@rhsoft.net wrote:
>
>
> Am 29.10.2013 21:25, schrieb Roman Gelfand:
>> The client is thunderbird. Correct me if I am wrong, it
Pascal Volk wrote:
> On 01/06/2010 05:29 PM Seth Mattinen wrote:
>> Does anyone know offhand where the logging string "delays=a/b/c/d" is
>> defined in the documentation? I can't seem to find it.
>
> see man postconf(5):
> man 5 postconf | less +/^delay_logging_resolution_limit
>
Ah, thanks. Eve
Seth Mattinen wrote:
> Does anyone know offhand where the logging string "delays=a/b/c/d" is
> defined in the documentation? I can't seem to find it.
>
Nevermind, it's in RELEASE_NOTES. I would humbly suggest putting it in
the DEBUG_README as well.
~Seth
On 01/06/2010 05:29 PM Seth Mattinen wrote:
> Does anyone know offhand where the logging string "delays=a/b/c/d" is
> defined in the documentation? I can't seem to find it.
see man postconf(5):
man 5 postconf | less +/^delay_logging_resolution_limit
Regards,
Pascal
--
The trapper recommends tod
26 matches
Mail list logo
