 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Postfix-users | May-2008 | Next-Thread | Next-Msg |
| Subject: | RE: mailq lockups |
| Group: | Postfix-users |
| From: | Joey |
| Date: | 6 May 2008 |
> From: owner-postfix-users
[mailto:owner-postfix-users]
> On Behalf Of Victor Duchovni
> Sent: Monday, May 05, 2008 10:33 PM
> To: 'postfix users list'
> Subject: Re: mailq lockups
>
> On Mon, May 05, 2008 at 10:08:29PM -0400, Joey wrote:
>
> > OK first let me clarify that I am not saying postfix is to blame, I
think
> it's exchange, but that???s not the point.
> > I am looking to understand/learn what is going wrong and see how on the
> postfix side I can figure out whats going on.
> > This is happening from 3 postfix servers, and happening to several
clients,
> me being the common factor.
> >
> > These two links will show you the connections on the exchange side:
> > http://www.web56.net/ebay/retries1.jpg
> > http://www.web56.net/ebay/retries2.jpg
>
> This is sadly useless. This would be a good time to report a complete
> "postconf -n".
>
> Look at *your* connection table with
>
> # lsof tcp@remoteip:25
>
> for each connection in an "ESTABLISHED" state, and a corresponding "smtp"
> process id, find the process start time (ps -o pid,stime,comm -p $pid)
> and check whether the process reported any previous deliveries between
> the start time and the present. The age of the connection (if not cached)
> is measured approximately from the later of the process start time and
> the last completed delivery report.
>
> If no long-lived connections exist on the Linux end, find out why Exchange
> still believes there are unfinished connections (this is where packet
> captures and verbose logging are handy).
>
> > My question is 1st: Why does the postfix timeout not drop the connection
> > on the postfix side ( which may or may not drop the exchange side it of
> > course has no control of that ) This shows me the connection is active,
> > and it's longer then the timeouts in postfix.
>
> We have no evidence for the premise (Postfix keeping idle connections
> alive for a long time), so it is to early to comment on the veracity
> of the conclusion. Postfix will normally terminate a delivery after 5
> hours even if the remote end avoids idle timeouts by gradually receiving
> trickles of traffic. When you report connections are 12+ hours old
> (not 10 days as before), the evidence is not entirely plausible.
>
> > 3F18D2A08A6* 6389 Sat May 3 09:20:37 hocxpx
> > sixo
> >
> >
> > 2nd: with the settings I have is there something additional I should be
> setting to insure I drop my connection if their connection takes too long?
> >
>
> You are jumping to conclusions. First find the real facts of the
situation.
>
> > I think these are logical questions to ask and please understand I
> > am not fully versed in all of the high level things that happen during
> > normal and abnormal email communications. Hence why I am here asking....
>
> The questions are only "logical" if you take major leaps of faith to
> accept the ambiguous evidence from the Exchange connection table, and
> also accept that the connections are still active on the Postfix side.
>
> It is far more likely that the leaps are unjustified than that Postfix
> is actually keeping SMTP connections alive for 12+ hours.
>
> No further progress is possible until you substantiate your conjectures
> with detailed research to uncover and report the actual events.
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:majordomo?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
I agree with what you are saying.
Definately exchange is keeping those connections open for an excessive
amount of time, and the postfix side does get dropped at some point.
Even after the postfix side drops the connection, exchange still shows them
as open. It looks like postfix is dropping the connection at about 10
minutes.
On the exchange side those connections remain open and basically don't close
unless terminated.
One thing I noticed is it appears that some messages make it through without
problem, while certain messages which look like they are spam are the ones
locking up. The exchange server has no anti-spam applications or anti-virus
so that's not what stopping it. This seems to be true in all 3 servers this
is happening in.
My postconf -n looks like this:
alias_maps = hash:/etc/postfix/aliases
biff = no
body_checks = pcre:/etc/postfix/body_checks
body_checks_size_limit = 21200
bounce_queue_lifetime = 1d
bounce_size_limit = 2048
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
delay_warning_time = 24h
deliver_lock_attempts = 10
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = 122.122.122.122
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 35000000
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 5d
message_size_limit = 20000000
mydestination = $myhostname, localhost.$mydomain, $mydomain
myhostname = mail.ispserver.net
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = /etc/postfix/backup_domains
relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients,
hash:/etc/postfix/transport_recipients
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
show_user_unknown_table_name = no
smtp_bind_address = 122.122.122.122
smtpd_delay_reject = yes
smtpd_hard_error_limit = 3
smtpd_helo_required = yes
smtpd_junk_command_limit = 3
smtpd_recipient_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination, check_helo_access
hash:/etc/postfix/helo_access, reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname, check_policy_service
unix:private/policy, check_sender_access
hash:/etc/postfix/client_checks, check_client_access
hash:/etc/postfix/client_checks, check_sender_access
hash:/etc/postfix/freemail_access, check_recipient_mx_access
hash:/etc/postfix/mx_access, reject_unauth_pipelining,
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org,
check_recipient_access hash:/etc/postfix/filtered_domains
smtpd_restriction_classes = from_freemail_host
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
soft_bounce = no
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport,
hash:/etc/postfix/transport_bounce
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
THANKS!
| Prev-Msg | Prev-Thread | Postfix-users | May-2008 | Next-Thread | Next-Msg |