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? But client ought not time out *too* quickly(!) ... busy mail server might occasionally be slugish in some responses. And fairly common in anti-spam to have some delay(s) in some responses ... clients which continue before getting a valid response are often spam sources and not RFC compliant, and may often be rejected. So ... *some* delay (but not "excessive") in there should be expected and tolerated by legitimate clients.

I'll check logs further, see if I can find anything else more conclusive.

From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: postmaster.rfc-clueless.org postmaster@balug.org Date: Mon, 09 Oct 2017 00:35:53 -0700

So, checking further, some bits I note/find: http://rfc-clueless.org/pages/listing_policy-postmaster ... if ... it is permissible to reject the null-envelope ('<>') to the postmaster address. However, doing so may prevent you from completing the unlisting process ... testing up through null (<>) sender, both IPv4 and IPv6, after an initial temp failure (graylist - expected - delay of 120 seconds), we have ... from some rather minimal legal testing - and quite the same for both IPv4 and IPv6 ... $ telnet 198.144.194.238 25 ... 220 . HELO [198.144.194.235] 250 balug-sf-lug-v2.balug.org Hello tigger.mpaoli.net [198.144.194.235] MAIL FROM:<> 250 OK RCPT TO:postmaster@balug.org 250 Accepted DATA 354 Enter message, ending with "." on a line by itself From: <> To: postmaster@balug.org

not an empty body (IPv4) . 550-Invalid message header syntax. ... 550 . checking exim4 logs, we have ... 2017-10-09 00:19:43 ... F=<> rejected after DATA: Sender : missing or malformed local part: failing address in "From:" header is: <> So, probably some overly aggressive anti-spam from eximconfig within exim4 MTA configuration ... I'll see what I find.

And that may not be what caused the listing to have occurred ... but it may be sufficient to prevent delisting.

...

From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: [BALUG-Admin] DNSBL: lists.balug.org Date: Sun, 08 Oct 2017 23:42:19 -0700

...

Thanks, checking into it ... looks like they have @balug.org listed for (allegedly) not accepting email to postmaster@balug.org, the others are listed "indirectly" ... apparently they're automagically listed as being subdomains of @balug.org (and perhaps also with the criterial that @balug.org is a domain that is supposed to accept email).

I did retest, seems to accept email to postmaster@balug.org just fine. But I'll check further. The only bits I can think of (and if so, may find in logs or through further testing), graylisting - shouldn't be an issue, but perhaps false positives from that? False positives from "spam" rejection? - only particular known issue is blank body rejection - but that would only show with an actual submission attempt, including (and concluding) with a blank body (or one that evaluated to blank/empty, after stripping out embedded images and the like).

Anyway, will review relevant logs and test further. I believe it also works fine on both IPv4 and IPv6 ... in any case, will check further and see if I can get it cleared up.

That seems to be the only blacklist (purported) issue, and just with the one domain (and subdomains "guilty" by association).

Also, at this point, @temp.balug.org should no longer be originating (and SPF data was suitably updated earlier), but it should still be accepting fine. Since it should be no longer be originating at all, if there's anything that's specific to @temp.balug.org (and not "mere" guilt by association with @balug.org), that's probably at most low priority issue on blacklist(s) or the like.

...

From: "Rick Moen" rick@linuxmafia.com Subject: [BALUG-Admin] DNSBL: lists.balug.org Date: Sun, 8 Oct 2017 21:56:50 -0700

...

Michael P.:

I periodically check my mail server IP on http://multirbl.valli.org/ and/or http://www.dnsbl.info/ , to make sure it's not on any blocklist. (It was recently on one for cryptic reasons. When I politely inquired and stressed that I'd be glad to fix any problem but didn't understand the existing one, the listing was removed without comment.)

$ host lists.balug.org lists.balug.org has address 198.144.194.238 lists.balug.org has IPv6 address 2001:470:1f04:19e::2 lists.balug.org mail is handled by 100 mx.lists.balug.org. $

http://multirbl.valli.org/lookup/198.144.194.238.html shows that one cluster of blocklists, the rfc-clueless.org one, doesn't like your IP. This is the successor to Derek Balling's rfc-ignorant.org DNSBL, which Derek eventually shut down, and has the same mission. The listing policy is here: http://rfc-clueless.org/pages/listing_policy

Looks like they believe that 198.144.194.238 isn't accepting mail to postmaster. an RFC requirement for any FQDN that deals in SMTP (http://rfc-clueless.org/pages/listing_policy-postmaster).

When I did a quick check telneting to 25/tcp, it seems to me that the system _was_ going to accept my manually composed mail to postmaster@lists.balug.org -- so I'm unclear on why that listing's there.

Seems like they also have no-postmaster listings for FQDNs balug-sf-lug-v2.balug.org, balug.org, and temp.balug.org. Maybe you should actually cease accepting mail for those FQDNs.

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.

Delisted ... almost? Well ... drats ... looks like that was a false *negative*. *Didn't* show on http://rfc-clueless.org/lookup/balug.org But did still show in DNS :-/ ... and hit authoritative NS directly to aviod any cached issue(s): $ dig @rbl.saverpigeeks.com. +norecurse +noall +answer balug.org.postmaster.rfc-clueless.org. A balug.org.postmaster.rfc-clueless.org. 4800 IN A 127.0.0.3 $ Reloaded the web page: http://rfc-clueless.org/lookup/balug.org And, buggers, still shows there after a reload. Checking /var/log/exim4/reject* ... nothing relevant since it was submitted to be cleared, only newer failures/rejects logged for postmaster@balug.org are all of the type: auth_server_login authenticator failed for (User) And even at that, all but one of those from the same IP (from Chile, and one from Netherlands). Also noticed newer /var/log/exim4/spamlog ... checked the newer stuff there and ... nothin' there but pure spam. And, nothing relevant received by postmaster@balug.org.

Will check again further later, but can't find any reason it shouldn't have already cleared by now.

From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] postmaster.rfc-clueless.org postmaster@balug.org Date: Mon, 9 Oct 2017 10:18:43 -0700

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

...

I think I generally, if not entirely, have callouts (at least SMTP callouts) disabled.

I hope you understand that was just an offhand guess. I really wouldn't know root cause, but your bit about swap seems entirely likely.

...

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.

This is annoyingly typical.

It's not unknown for their checking scripts to simply glitch.

...

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.

How odd. multirbl.valli.org purports to spawn off real-time checks of each of the several hundred DNSBLs, or that's my understanding. Anyway, glad checking the individual DNSBL found no listing.