I did read the web page, but I don't understand if the packet itself has to
end with a \r\n ... what if the next packet actually has the \r\n in it, but
qmail didn't read it because it already sent the error message?
If you've telnetted to port 25 and are typing in commands directly, each
character gets it's own packet, so qmail-smtpd must be listening for \r\n to
find things to act on, yes? So, why does this packet give qmail problems?
-ben
on 2/23/00 4:41 PM, Adam McKenna at [EMAIL PROTECTED] wrote:
> If you read the "blah, blah", and go to the website mentioned, you will find
> out exactly what the problem is.
>
> --Adam
>
> On Wed, Feb 23, 2000 at 03:41:00PM -0800, Ben Houston wrote:
>> I used snoop on Solaris to capture the packets on port 25... The first
>> exchange seems fine, I see a DATA command, qmail says "354 go ahead". Then
>> there's a packet whose data ends with \r\n from the client, empty response
>> from server, then there's a packet with this in it:
>>
>> "X-EM-Version: 4, 5, 0, 6\r\nX-EM-Registration: #3113420714600B"
>>
>> Immediately following this packet is the 451 See blah blah... response from
>> the server.
>>
>> Does this seem right? Does that packet need to end with \r\n? Should the
>> \r\n in the middle of the line not be followed with more information? It
>> doesn't seem like it should matter (especially since we're in the DATA part,
>> and smtp shouldn't be taking commands...)
>>
>> -ben
>>
>>
>> on 2/23/00 1:18 AM, Anand Buddhdev at [EMAIL PROTECTED] wrote:
>>
>>> On Tue, Feb 22, 2000 at 05:06:00PM -0800, Ben Houston wrote:
>>>
>>>> I think there's a problem with the software he's using... could it be the
>>>> Bare LF problem? I know I haven't been able to supply much information
>>>> here,
>>>> but that's because I can't seem to find log entries (apparently qmail-smtpd
>>>> doesn't have any), and I'm not sure how to continue. Any similar
>>>> experiences
>>>> or suggestions for a course of action? Thanks for your help...
>>>
>>> You can use recordio from the ucspi-tcp package to record the entire
>>> conversation from that database application. Then you'll know if it's a
>>> bare LF problem or something else.
>>
>
