Call for INN 2.5.2 testing (new NNTP RFC 3977)

Julien ÉLIE julien at trigofacile.com
Sat Nov 21 11:46:51 UTC 2009


Hi Russ,

>> Message-ID: <slrn20091109075439.943.twooffive at may.eternal-september.org>
>
>> Very strange...
>> I have just checked every call to bad_messageid logging and when it occurs,
>> it is because the message-ID is found to be invalid and no posting is done.
>
> I've seen things like this happen if there's some subtle boundary
> condition that can cause the algorithm to read past the beginning or end
> of the string by one character.  That one character is *usually* a nul,
> and hence everything works, but sometimes it's not.  It's a typical
> problem in C, where doing string handling properly is tricky.

I unfortunately did not find such a thing in the algorithm used to
check the validity of a message-ID.


But I found out another issue (not related with this one).

I only managed to obtain bad_command, not bad_messageid...

Nov 21 11:13:48 news innd: localhost connected 637
Nov 21 11:13:48 news innd: localhost:637 bad_command IHAVE <left at right>
Nov 21 11:13:48 news innd: localhost:637 closed seconds 0 accepted 0 refused 0 rejected 0 duplicate 0 accepted size 0 duplicate size 
0 rejected size 0
Nov 21 11:13:48 news nnrpd[13749]: localhost.localdomain ihave ok <left at right>

It happens when I post messages containing something like:

Message-ID: <left at right>\r\n\t\r\n


Message-ID: <left at right>\r\t\r\n


nnrpd answers with:
---
235 Article received <left at right>

---

Therefore, it becomes a multi-line answer...
235 because innd sends 500 and nnrpd spools the message for later delivery
by rnews.

Why 500?
No parsing is attempted by innd when it receives
IHAVE <left at right>\n\t\r\n
(nnrpd replaces "\r\n" with "\n" in headers)
because of that code in nc.c:

p points to the character just after the first '\n' found.

      if (p[-2] != '\r') { /* Probably in an article. */
        char *tmpstr;

        tmpstr = xmalloc(i - cp->Start + 1);
        memcpy(tmpstr, bp->data + cp->Start, i - cp->Start);
        tmpstr[i - cp->Start] = '\0';

        syslog(L_NOTICE, "%s bad_command %s", CHANname(cp),
          MaxLength(tmpstr, tmpstr));
        free(tmpstr);

        if (++(cp->BadCommands) >= BAD_COMMAND_COUNT) {
          cp->State = CSwritegoodbye;
          snprintf(buff, sizeof(buff), "%d Too many unrecognized commands",
                   NNTP_FAIL_TERMINATING);
          NCwritereply(cp, buff);
          break;
        }
        snprintf(buff, sizeof(buff), "%d What?", NNTP_ERR_COMMAND);
        NCwritereply(cp, buff);
        /* Still some data left, go for it. */
        cp->Start = cp->Next;
        break;
      }

I would suggest to remove that code.  Commands will be dealt with by
the rest of the code and will be properly discarded.
I do not see well the reason of that code here.

Without that code, it gives the right response from nnrpd:
437 435 Syntax error in message-ID

Nov 21 12:03:35 news innd: localhost:31 bad_messageid <hd4ohrsl$dddhscddddddjf7$1 at news.trigofacile.com
Nov 21 12:03:35 news innd: localhost:31 closed seconds 0 accepted 0 refused 0 rejected 0 duplicate 0 accepted size 0 duplicate size 
0 rejected size 0
Nov 21 12:03:35 news nnrpd[19831]: localhost.localdomain ihave failed 435 Syntax error in message-ID


We have a p[-2] = '\0' (which removed '>' in the message-ID above).
Maybe we should leave that, not trying to do p[-1] = '\0' in case
we do not have '\r'.  The command was initially broken here so better
not try to fix the received command ourselves.


Besides this change, I also suggest to check the message-ID header
in nnrpd (just calling the IsValidMessageId() function when processing
the message received via IHAVE or POST).
Because, as you may have noticed, innd is currently happily executing
any command that you can pass in the Message-ID: header...
Nothing tremendous we can do, though.


Anyway, I still do not understand the initial issue of the
thread, with the bad_messageid reported by Ray.  Please tell
us if you see it again.

And thanks, Alexander, for having sent an e-mail to your user.

-- 
Julien ÉLIE

« L'ordinateur obéit à vos ordres, pas à vos intentions. » 




More information about the inn-workers mailing list