Confusing issue with sendmail and unix.in

[xrobau]

I've got some messages that are getting stuck in the sendmail mailq:

Code: Select all

[root@mail tmp]# mailq
                /var/spool/mqueue (6 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
k6QLs2L6020895*     194 Thu Jul 27 07:54 <range@client.com.au>
                 (reply: read error from mail.server.com.au)
                                         <gina@server.com.au>
k6Q86uX8015686      779 Wed Jul 26 18:06 <range@client.com.au>
                 (reply: read error from mail.server.com.au)
                                         <gina@server.com.au>
k6Q6wueX015092    63004 Wed Jul 26 16:58 <range@client.com.au>
                 (reply: read error from mail.server.com.au)
                                         <bonnie@server.com.au>
k6O83KcS025129    65020 Mon Jul 24 18:03 <range@client.com.au>
                 (reply: read error from mail.server.com.au)
                                         <tracey@server.com.au>
k6O7hSSb024937    65020 Mon Jul 24 17:43 <range@client.com.au>
                 (reply: read error from mail.server.com.au)
                                         <tracey@server.com.au>


and when I ask sendmail for debugging:

Code: Select all

[root@mail tmp]# sendmail -v -d10-12.32 -qIk6Q86uX8015686

Running /var/spool/mqueue/k6Q86uX8015686 (sequence 1 of 1)
--deliver, id=k6QLs2L6020895, mailer=scalix, host=`mail', first user=`gina@server.com.au'
remotename(<range@client.com.au>)
remotename => `range@client.com.au'

send to 0x9cdb6b0=<gina@server.com.au>:
        mailer 10 (scalix), host `mail'
        user `gina@server.com.au', ruser `<null>'
        state=OK, next=0x0, alias 0x0, uid 0, gid 0
        flags=80000182<QPRIMARY,QPINGONFAILURE,QPINGONDELAY,QRCPTOK>
        owner=(none), home="(none)", fullname="(none)"
        orcpt="(none)", statmta=(none), status=(none)
        finalrcpt="RFC822; gina@server.com.au"
        rstatus="(none)"
        statdate=(none)
ctladdr=[NULL]
openmailer: unix.in -s mail
<gina@server.com.au>... Connecting to mail via scalix...
openmailer: running as r/euid=8/8, r/egid=12/12
220 Scalix ESMTP Ready.
>>> EHLO mail.serverl.com.au
250-Hello, pleased to meet you.
250 DSN
openmailer: MCI@0x9cec3e8: flags=808<ESMTP,DSN>,
        errno=0, herrno=0, exitstat=0, state=2, pid=24979,
        maxsize=0, phase=client EHLO, mailer=scalix,
        status=(null), rstatus=(null),
        host=(null), lastuse=Thu Jul 27 10:22:24 2006

>>> MAIL From:<range@client.com.au>
250 Ok
>>> RCPT To:<gina@server.com.au>
250 Ok
>>> DATA
354 Enter mail, end with "." on a line by itself.
remotename(Mobil Range <range@client.com.au>)
remotename => `Mobil Range <range@client.com.au>'
remotename("range@client.com.au" <range@client.com.au>)
remotename => `"range@client.com.au" <range@client.com.au>'
remotename("'Gina McMahon'" <gina@server.com.au>)
remotename => `"'Gina McMahon'" <gina@server.com.au>'
>>> .
Cannot read message data.
(I have to push ^C here to abort it, as it just sits there forever)
[root@mail tmp]#


I can't really debug unix.in, as when I try to do a strace -ff, it breaks DNS lookups (or something) and bounces the mail back to the sender. However, sendmail _IS_ definately sending the mail through to unix.in - I have, however, managed to accidently duplicate this issue when I was trying to strace unix.in by sending the message body and then closing stdout (stdin on unix.in) before sending the closing . - but as you can see the dot is definately being sent by sendmail.

Note that uid 8 and gid 18 are both 'mail' - should unix.in be running as 'scalix'?

I've had a look through the admin manual, but I can't find any explicit place to debug what's going in and out of unix.in!

FYI, this is a RHEL machine that was installed with the scalix installer.

Anyone have any clues?

--Rob

[xrobau]

After guessing that it _was_ a bug in unix.in, I started having a look through the headers of the message and starting to delete any suspicious lines. I discovered that unix.in is choking on this line:

Encoding: 12 TEXT

Yes, absoloutely, total garbage header, but that's what's breaking unix.in

Here's another line: (Pasting this here for google goodness)

Encoding: 6 TEXT, 1016 UUENCODE

This is what's being generated by older Outlook Express mail clients. So, currently, anyone sending any message to scalix (from certain versions of) Outlook Express is getting their messages dropped. When I take that line out of the message (in the mailq) it goes through fine.

The specific mail header is:
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211

Scalix, any change of a patch or fix?

--Rob

[ScalixSupport]

That header isn't garbage, it's RFC 1154.

What version of Outlook Express are you running with ? RFC 1154 is used by clients that aren't (typically) MIME-aware.

I have to say that, in the very near future, there isn't a chance of a patch but I'd still like a complete copy of the SMTP conversation so I can test it here. I can't give any commitment to fix but, if we do have a problem, I can raise a bug report. Please send it to support at scalix.com and mark it for my attention.

Cheers

Dave

[xrobau]

I'm heading back onsite tomorrow (they're 500km away), so I'll actually go and physically look at the machine that's having grief sending emails.. I'm _guessing_ that it's the OE that came with Windows 2000 - it's quite possible that the machine's never been upgraded.

I think I was sensible enough to grab a copy of the entire message from the mailq before I started fixing it, but if not, I'll just get them to send another email

--Rob

[xrobau]

II think I was sensible enough to grab a copy of the entire message from the mailq before I started fixing it, but if not, I'll just get them to send another email
--Rob

Indeed I was sensible enough. Sent.

--Rob

[ScalixSupport]

This is bug 12153, fixed for the next version of Scalix, Equinox.

Currently I would advise to filter out the Encoding: property from the message header.

This Encoding setting is used by ancient Microsoft clients and was superseded by MIME.

Cheers,

Sascha.