Yes, the delay bit ... callout check? Don't think so, I think I generally, if not entirely, have callouts (at least SMTP callouts) disabled. However, for anti-spam stuff, it may check URL(s), etc. - so that may explain bit of delay too. Seems also, sometimes, I see no (at least direct human detectable) delay.
Also very possible they delay may be due to (lack of) resources on the virtual host and swapping ... sometimes it's just a bit slugish to respond - and most of the time has some less-recently-used stuff swapped out. Notably the clamav piece is a bit RAM suck ... but fortunately it's also only one process and single threaded - so it doesn't baloon out when it's active ... it just swaps in - and some other stuff swaps out - and vice versa when it's relatively inactive and the other stuff active. Relatively typical state: $ free total used free shared buffers cached Mem: 1024424 944996 79428 7024 10464 72544 -/+ buffers/cache: 861988 162436 Swap: 1048544 546488 502056 $ Yes, swap used! 8-O But notice also fair bit of buffers/cache that can be shed if/when needed. Have also reviewed the sar data since adjusting Apache so it wouldn't baloon too much on memory consumption ... and things seem to continue with reason ... not exactly "high performance" or close to such ... but reasonably clear of critical shortage of (virtual) memory. So ... mostly "good enough" for system where performance isn't particularly critical. I should probably review the sar data again, but last I checked it looked reasonable on the memory/swap data ... again, not for *performance* - but for reasonable reliability (remains up and running, reasonably well clear of OOM PID killer and other highly sucky RAM/swap crisies).
And, as I mentioned earlier, delay(s) may be exim4/eximconfig anti-spam measures - notably look for protocol violating clients, which are generally spam clients (notably proceeding before receiving required response first).
Also did go over the /var/log/exim4/reject* log files. Found zilch that seemed applicable for postmaster@balug.org Other than my own apparent false positives (header of: From: <> apparently problematic and probably not legitimate - not to be confused with envelope null sender <>), there were only 2 types of rejects for postmaster@balug.org relay attempt rejects bad authentication attempt rejects ... that was it, nothing else - and that's going back to 2017-09-03T06:46:29-0700 ... I did earlier extend the logrotate retention, so I'd have more data to look back over if/when that was useful or needed. I did also look particularly carefully around 2017-09-27 +- a few days, as the listing seems to imply it was listed around then.
Delisting? It, understandably, is an automated process - and did submit for delisting. Nothing's shown up ... yet - not email nor reject. But it's not super clear how quickly those happen - may take hour(s) to a day or so. Looking at some of the various data, notably TTLs and SOA serial number - seems likely updates happen somewhere between hour(s) and day or so ... but that may not include any latencies in processing queues, etc. Also can only submit for delisting max of once per 7 (or 8) days ... understandable that. Anyway, hopefully clears on the first retest. Not sure if there's any received email content I may have to use or refer to - or if it's fully automatic.
Also, http://multirbl.valli.org/lookup/balug.org.html looks moderately out-of-date. It shows listing on bl.fmb.la - but in checking source - both web and DNS - that's already cleared.
So ... at this point, seems mostly matter of wait and watch.
From: "Rick Moen" rick@linuxmafia.com To: balug-admin@lists.balug.org Subject: Re: [BALUG-Admin] postmaster.rfc-clueless.org postmaster@balug.org Date: Mon, 9 Oct 2017 01:40:08 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
And ... perhaps that was false positive ... if I drop out the header: From: <> and don't even give a From: header at all, those same quite minimal email tests make it through just fine. I did notice sometimes there's substantial delay (maybe up to about 10 seconds or so) after: RCPT TO:postmaster@balug.org and before it responds with: 250 Accepted ... but even in "worst case", that probably ought only cause some temp failure if client times out on that?
Yes, I noticed this, too. (Might have been the delay while callout check of the delivering IP was underway.)
I haven't looked up rfc-clueless.org's delisting procedure. Some DNSBLs ask you to send mail somewhere making the request. If that's the case, then I suppose you could send the relevent telnet transcript, showing RFC compliance.
People running DNSBLs tend to be cranky and cynical, or become that way if they aren't already. They're also overly busy and wary of comminication with complaining sysadmins as a time sink. However, when all is said and done, they do try to work with sysadmins who _are_ playing by the rules.