On 24 Jul 2014, at 06:37, McKinnon Chris <crmckin...@shaw.ca> wrote: > I checked for “connect from unknown” errors coming from the client IPs in > mail.log and I’m not seeing any. The only warning I see for one client is: > > Jul 23 19:21:54 ravenviewhomes.com postfix/smtpd[61133]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > Jul 23 19:22:39 ravenviewhomes.com postfix/smtpd[61179]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > Jul 23 19:23:57 ravenviewhomes.com postfix/smtpd[61179]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > Jul 23 19:24:44 ravenviewhomes.com postfix/smtpd[61179]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > Jul 23 19:25:51 ravenviewhomes.com postfix/smtpd[61179]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > Jul 23 19:25:58 ravenviewhomes.com postfix/smtpd[61179]: warning: > fqdn_hidden[ip_hidden]: SASL PLAIN authentication failed: > > This appears to have been a temporary issue as the client had hundreds of > successful connection attempts today. > > I had the clients attempt the telnet connect at least 10 times and I’m told > that they got the “220” response quickly each time. The slowness is not > consistent unfortunately. It seems to be intermittent. With many emails > sending immediately or after 5 seconds or so but a few taking 40-60 seconds. > Size of the email doesn’t seem to be a factor.
At this point, I'd recommend that you either start posting real, unedited log data, or have someone with the appropriate skillset look at the actual configuration, logs, and so on. The data you have shared thus far doesn't say a whole lot, and you have changed so many things since you had a working setup that what used to work is pretty much irrelevant by now. Also, if you want to 'anonymize' configuration or log entries, do not use someone else's domain; > mydomain = abc.com > myhostname = mail.abc.com It is exceedingly unlikely that that domain is actually under your control, and that you are running the mail server for it. Use the reserved example domains, if you must; http://www.iana.org/domains/reserved As for resolving your problem, test. Test and measure. Identify common patterns; does it only occur when users are mobile, or only when they are at the office, etc. Test with different client applications, preferably from the same machine that has the problem. Use a webmail client, for example, or something like Swaks; http://www.jetmore.org/john/code/swaks/ Run any tests both locally, on the server itself, and remotely from any clients that talk to it. Make sure that you are looking at ALL the logs that Postfix might write to. This means looking at checking '/var/log', but also '/Library/Logs/Mail' for example, depending on how much of the default setup is still intact. With this, narrow down the problem. Eliminate possible causes. It might turn out to be something outside the server itself, such as malfunctioning DNS servers for the clients, a change in the configuration of the clients, or hardware that went bad. Mvg, Joni
