Hi, I have a customer who has a PHP application which sends invitations for events to users selected in the database. No Spam, all is very legit and normal business mail. I gave the developer a mail account on my mail1 but the sending the mail is always delayed, from between 8 seconds and 30 seconds. The machine is running nearly zero load and has no other problems I know of. The customer is getting impatient. How can I remove this delay? I am running Debian 10 and a current version of ISPConfig3. Yours sincerely Stefan
You can probably find and work on delays in your server, but just as a matter of expectations, email is designed to be reliable, not instant; I personally wouldn't consider that amount of time to be of any concern. First identify where the delay is of course, then see what needs done. Name service/DNS lookups are a likely candidate. Send a test email via their application and post full mail logs for that email (including rspamd.log entries if you use rspamd) along with message headers as you receive them. Is your mail server configured to use a local (ie. on the mail server itself), caching DNS server? How is mail submitted? Eg. I presume you use authentication, but what port? If not already using a submission port (465 or 587), try switching to that instead of sending on 25. Do you have any rbl's in use? Typically those would be on port 25, not 465/587, so this may be a moot point after addressing that. Just as a heads-up if you want to get a jump on the next step, if the above doesn't find anything conclusive, the next step is likely to be enable peer debugging in postfix for the web server's ip and digging through those logs.
How does that customer even know e-mail is delayed 30 seconds? Ask a copy of those delayed e-mails from the recipient with full headers. The examine the received lines, and other timestamps. They should show where that 30 seconds is spent. It can be on the recipients system doing spam filtering of what-not.
Its not the end-customer, meaning the receiver of the email who is complaining but our customer - now it gets complicated - who hired another company to write a programm which invites people to events (I guess this is just one function) and if you invite 300 people and that takes 3000 seconds the customer (our customer) gets annoyed - at us and and at the company who wrote the script. I usually use Port 465 but I will ask the other company to try another port.
No, I dont use it as a local caching server. Considering the way you are asking you most likely believe I should set up one, which I will do. If ISPConfig does not configure the use of any RBLs then there are none. Which files do I need to examine to get all information about the email? /var/log/mail, /var/log/rspamd/, /var/log/messages. Which else? I found a huge amount of lines like these in /var/log/rspamd.log.1 How can I fix this? It looks like some program, possible redis should be running but is not. 2022-06-22 14:34:32 #17910(rspamd_proxy) <xfexjn>; lua; lua_redis.lua:837: cannot upload script to 127.0.0.1: Verbindungsaufbau abgelehnt 2022-07-11 13:52:10 #17915(normal) rspamd_redis_stat_keys: cannot get keys to gather stat: Verbindungsaufbau abgelehnt (Verbindungsaufbau abgelehnt means Connection Denied) Yours Stefan
Probably just /var/log/mail.log and /var/log/rspamd/rspamd.log. Did this fix things so they are working better/faster?
Have you examined the script that does the sending? When I have written something similar, I have added delay before sending the next e-mail to not flood the server with thousand messages per second. Maybe debug the script, make it print timestamps to see where it waits for something?
Hi, dnsmasq brought only a minor improvement. I tested it on my machine and it reduced the lookup from 15ms to 0 (doh) with cached replies, but installing it on the server did not bring any change. This was brought on by installing redis. My colleague contacted me today to tell me that the time to send an email was reduced from 8000 ms to 85ms. I guess this means one should never install rspamd without redis. Thanks for your advice, gentlemen! Stefan
