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

[Michael Paoli]

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.