Mailing List SIMS@mail.stalker.com Message #5686
From: Bill Cole <listbill@scconsult.com>
Subject: Re: 2 questions - blacklisting followup
Date: Thu, 30 Mar 2000 10:46:35 -0500
To: SIMS Discussions <SIMS@mail.stalker.com>
>Based on previous spams that I can't believe I misinterpreted, I
>blacklisted a PSI dialup block from which we had received a direct
>connection. PSI is our ISP, so they provide our mail backup. But near
>as I can tell, PSI removed or otherwise retired the dialup block, and
>assigned one of the IPs to a mailserver. And you guessed it -
>thinking that I was still blocking a dialup range, I instead began
>blacklisting a box occasionally used to try to deliver mail to us.
>
>The range is 38.8.111.1-38.8.111.254. Of course, it does not now
>return a dialup block.
>
>Question one: is there a way to find out how an IP block -used- to be
>assigned?

Ask the ISP. They may or may not answer, they may or may not know. There
is no other reasonably reliable source.

>This is to prove to myself I'm not crazy. Do ISPs do this
>sort of thing (reassign entire blocks) often?

Yes. PSI is especially prone to this because they provide a wide range of
services and they have that Class A network. They can fiddle with it at
will without causing trouble because they have no risk of anyone else ever
announcing routes for anything in 38.*.

>Second, a list mom/postmaster who first alerted me to the issue
>tracked me down via the customized error message SIMS sends back when
>we reject via the blacklist. After we resolved everything, he wrote
>me this:
>
>"Now, any chance of your mail server returning RFC 1894-compliant DSNs?
>If I hadn't been dealing w/ your DSNs by hand, I'd have never noticed
>them."
>
>
>I'd like to answer him intelligently. I at least looked at 1894 and
>now know that DSN is Delivery Status Notification. Is he saying that
>if this was being handled in automated fashion on his end... well,
>what the hell -is- he saying anyway?

He's wrong. If SIMS rejects a message before actual delivery, it is not
responsible for generating a 1894 DSN, the machine offering the message
is. See Figure 1 in 1894. SIMS is the 'Remote MTA' not the 'Receiving MTA'
in that diagram.

>I am perusing 1894 but frankly, it is so detailed I figured I might
>get a quicker answer from the list. The message returned by SIMS (via
>the backup server) is currently:
>
>host mail.4pi.com [206.6.156.11]:
>591 Your host is in our Black List. No mail will be accepted. Refer to
><http://www.4pi.com/home/spam.shtml> for more information.
>
>I know this is what the other postmaster received, as he quoted it.
>What's wrong with this? I can't tell from the rest of headers if our
>backup server at PSI returned an additional message which itself is
>not RFC compliant. Is this message not compliant somehow? Even though
>we can modify SIMS STR# resources, should we really not be doing this?

That message happens as an answer to the RCPT command. The MTA that
receives that error is responsible (as the "Reporting MTA") for generating
any DSN.

However, there is a standards issue with SIMS error messages. Basically
there are no standards for SMTP reply codes (i.e. the ### numbers) beyond
some defined in RFC821 and a theory for building other reply codes defined
there. SIMS has reasonable non-standard reply codes conforming to that
theory. There is also a widely-misunderstood enhanced status code system
(RFC1893 and RFC2034) which defines more codes that are supposed to come
after the reply code, IF the MTA supports that extension to SMTP.
Unfortunately, SOME MTA's and response-parsing software expect that
extension without checking for it, and go further to demand something like
this:

571 5.7.1 Message rejected by policy


The #.#.# number is the RFC1893/2034 "enhanced status code," and SOME
tools expect that the RFC821 reply code match the enhanced status code.
Those are broken tools. The entire rationale for enhanced status codes was
that reply codes are a mess and that some standard system apart from the
reply code was needed to define status responses more finely in a standard
way. SIMS does not support the RFC1893/2034 system, although is it
possible to hack in appropriate strings to yield compliant extended
responses like this:

591 5.7.1 Your host is in our Black List.

This MIGHT cause some broken software to better understand the SIMS
responses.  I say 'broken' because it is absolutely possible for a
compliant RFC1894 DSN 'Reporting MTA' to generate meaningful and correct
DSN's based on the standard SIMS rejection responses NOW without any
change. The clue needed is that any 5xx response code is a permanent
failure, and any MTA not recognizing that is going to break with more than
SIMS.


I suspect that what is actually happening in your case is that the sending
MTA is the list software, and that it does not understand anything beyond
the specific reply codes defined in RFC821, and possibly the enhanced
status codes defined in RFC1893 returned by the mechanism described in
RFC2034. It may also understand RFC1894 DSN messages, but it isn't getting
one because the failure is too close.

--
Bill Cole

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster