[UCIMC-Tech] IMC-bookkeeper list not working - getting 554 error "service not available" (gmail considered unsafe, but doesn't need to be -- +fix)

[Stuart Levy]

This is a mostly tech reply so not cc'ing finance...

On Wed, Jan 09, 2008 at 01:19:34PM -0500, Danielle Chynoweth wrote:
> Is this a temporary or permanent problem?  I have had mail from IMC
> Bookkeeper bounce before, but not mail from other IMC lists. Have others
> experienced the same? - D
> 
> ---------- Forwarded message ----------
> From: Mail Delivery Subsystem <mailer-daemon at googlemail.com>
> Date: Jan 9, 2008 1:14 PM
> Subject: Delivery Status Notification (Failure)
> To: arthousefarm at gmail.com
> 
> 
> This is an automatically generated Delivery Status Notification
> 
> Delivery to the following recipient failed permanently:
> 
>     imc-bookkeeper at lists.chambana.net
> 
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 13): 554 Service unavailable; Client host [
> 64.233.166.181] blocked using multihop.dsbl.org;
> http://dsbl.org/listing?64.233.166.181

This seems to mean that multihop.dsbl.org is listing 64.233.166.181,
one of google's mail servers, as a possible open mail relay.

That affects any mail server (including the IMC's) that uses
multihop.dsbl.org to decide whether mail from a given source is
liable to be safe.

Specifically it looks as though the IMC server will reject *some*
messages coming *from* gmail.com users.  If I'm guessing right, failures
may look random -- whether a message is accepted might depend on
just which gmail server happens to pass it to the IMC mail server.

If that gmail server got listed as a multihop-possible-open-relay,
then it'll fail.  But maybe some got listed that way while others didn't.
E.g. 64.233.166.181 is listed that way, but ...182 and ...183 aren't.

Digging through the past messages listed at the URL mentioned in the error,
   http://dsbl.org/listing?64.233.166.181

one person points out that "http://dsbl.org/usage" says

    Note that the multihop and unconfirmed lists are very aggressive and
    have the potential for a high level of false positives. The decision to
    block mail based on multihop, therefore, is philosophical as much as
    practical: doing so effectively punishes ISPs who do not proactively
    secure their networks by refusing significant legitimate mail from their
    customers. The unconfirmed list should only be used as part of a scoring
    system such as spamassassin, if at all.

They seem to suggest that "list.dsbl.org" is a pretty
reliable guide to unsafe mail servers whose output shouldn't
be trusted, but that using "multihop.dsbl.org" is liable to
cause trouble just like this case.

If other techies agree that this is the problem,
then a fix could be, on imsahp in /etc/postfix/main.cf
to comment out the line (line 415) which says

        reject_rbl_client multihop.dsbl.org

and then restart postfix (I don't know how to do that on Debian).
This would still leave the "reject_rbl_client list.dsbl.org"
on the previous line.

>   ----- Original message -----
> 
> Received: by 10.140.147.18 with SMTP id u18mr583620rvd.267.1199902433821;
>        Wed, 09 Jan 2008 10:13:53 -0800 (PST)
> Received: by 10.141.172.7 with HTTP; Wed, 9 Jan 2008 10:13:53 -0800 (PST)
> Message-ID: <e20736840801091013x7dd581f8t1e37831a5a7d6290 at mail.gmail.com>
> Date: Wed, 9 Jan 2008 13:13:53 -0500
> From: "Danielle Chynoweth" <chyn at ojctech.com>
> Sender: arthousefarm at gmail.com
> To: JOY <imcbooks at gmail.com>
> Subject: Re: [Imc-bookkeeper] Services Rendered
> Cc: imc-bookkeeper at lists.chambana.net
> In-Reply-To: <c6be167c0801090959p277a72a7r115647ea1ad1f761 at mail.gmail.com>
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
>        boundary="----=_Part_24946_3769132.1199902433817"
> References: <c6be167c0801090959p277a72a7r115647ea1ad1f761 at mail.gmail.com>
> X-Google-Sender-Auth: a897c8c2f8ef56d7
> 
> ------=_Part_24946_3769132.1199902433817
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline

> _______________________________________________
> IMC-Tech mailing list
> IMC-Tech at lists.ucimc.org
> http://lists.chambana.net/cgi-bin/listinfo/imc-tech