[BALUG-Admin] postmaster.rfc-clueless.org postmaster@balug.org

[Michael Paoli]

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.
>