Re: [fetchmail-devel] Re: fix listener mode

[Matthias A. <mat...@gm...>]

Sunil Shetye <sh...@bo...> writes:

>> Wow, that patch is huge.  I'll happily merge it or something similar
>> onto the trunk (cleanup is always good), but for 6.3.1 I'd prefer a
>> smaller patch, even if it means hacking the state structures in some
>> places (for instance, upon sending a bounce and completion of the bounce
>> function).
>
> There are two problems that that patch fixes:
>
> - After switching to LMTP mode when trying out multiple smtphosts,
>   fetchmail never switches back to SMTP mode and continues talking
>   LMTP to the next SMTP socket. In daemon mode, it will not even talk
>   SMTP on the next poll of that mailserver.
>
> $ fetchmail -v --smtphost /this/socket/is/down,localhost
>
>   The source of this problem is that ctl->listener is never reset to
>   SMTP_MODE.
>
> - After sending a bounce, fetchmail does not switch back to LMTP mode
>   and continues talking SMTP to the LMTP socket. In daemon mode,
>   however, it will talk LMTP on the next run.
>
>   The source of this problem is that the global variable smtp_mode is
>   never reset to LMTP_MODE in that poll.
>
> A smaller patch can fix only one of the two issues. I assume that you
> are interested in keeping the global variable smtp_mode. The problem
> is that fetchmail has too many return points (including return via
> longjump()) and ensuring that smtp_mode is indeed reset to its
> original value in all cases is not going to really make the patch
> smaller.

OK. I'll consider the full thing for 6.3.2, but as the bug has been
found by you (as developer) and not by a user, I am inclined to assume
that LMTP is not in wide use (and after all, many sites interested in
LMTP would be using Cyrus, which has a "deliver" program, too), or if it
is, there are no SMTP fallback layers and perhaps no bounces.

I don't see why a site would use mixed LMTP/SMTP delivery. It's the same
story as with fallback MDA: it just introduces inconsistencies by going
several inbound paths, which many sites will probably rather avoid.

-- 
Matthias Andree