Mailing List Archive

Problem in patched qmail-remote.c
Hi,

I think I found a potential bug in patched versions of qmail-remote.c,
specifically versions where the smtp() function might return on a 4xx
response.
When the first MX has a problem that causes qmail-remote to try the
second MX, the substdio buffer for smtpfd may still contain crap (stuff
after "4xx ...\r\n" sent by a broken server) from the first MX and cause
a wrong answer from smtpcode() for the second MX. smtpcode() sees
something like "crapcrap220...", which causes it to return a wrong
answer. This in turn makes the second MX unusable.

My solution is to init the substdio on each MX try, what do you think?

The patch is against the (unaffected!) unpatched qmail-1.03, but it
shows what I did.

regards,
Franz
Re: Problem in patched qmail-remote.c [ In reply to ]
On Tue, 8 Nov 2022 at 19:41, Franz Sirl <Franz.Sirl-qmail@lauterbach.com> wrote:
>
> Hi,
>
> I think I found a potential bug in patched versions of qmail-remote.c, specifically versions where the smtp() function might return on a 4xx response.
> When the first MX has a problem that causes qmail-remote to try the second MX, the substdio buffer for smtpfd may still contain crap (stuff after "4xx ...\r\n" sent by a broken server) from the first MX and cause a wrong answer from smtpcode() for the second MX. smtpcode() sees something like "crapcrap220...", which causes it to return a wrong answer. This in turn makes the second MX unusable.

This is nice. I haven't encountered this till now. But I guess this
could be possible if the remote smtp prints multiple lines after the
last last line of the EHLO response. But honestly I haven't thought
through this fully yet. I will try this by modifying qmail-smtpd to
simulate this problem.

>
>
>
> My solution is to init the substdio on each MX try, what do you think?
>
> The patch is against the (unaffected!) unpatched qmail-1.03, but it shows what I did.
>
This should also work

smtpfrom.p = 0;

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Problem in patched qmail-remote.c [ In reply to ]
Wouldn't the right choice be to set smtpfrom.p = smtpfrom.n? That is the "ring buffer empty" case.

On 8 November 2022 15:14:12 UTC, Manvendra Bhangui <mbhangui@gmail.com> wrote:
>On Tue, 8 Nov 2022 at 19:41, Franz Sirl <Franz.Sirl-qmail@lauterbach.com> wrote:
>>
>> Hi,
>>
>> I think I found a potential bug in patched versions of qmail-remote.c, specifically versions where the smtp() function might return on a 4xx response.
>> When the first MX has a problem that causes qmail-remote to try the second MX, the substdio buffer for smtpfd may still contain crap (stuff after "4xx ...\r\n" sent by a broken server) from the first MX and cause a wrong answer from smtpcode() for the second MX. smtpcode() sees something like "crapcrap220...", which causes it to return a wrong answer. This in turn makes the second MX unusable.
>
>This is nice. I haven't encountered this till now. But I guess this
>could be possible if the remote smtp prints multiple lines after the
>last last line of the EHLO response. But honestly I haven't thought
>through this fully yet. I will try this by modifying qmail-smtpd to
>simulate this problem.
>
>>
>>
>>
>> My solution is to init the substdio on each MX try, what do you think?
>>
>> The patch is against the (unaffected!) unpatched qmail-1.03, but it shows what I did.
>>
>This should also work
>
>smtpfrom.p = 0;
>

--
Ellenor Bjornsdottir (she)
sysadmin umbrellix.net