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.