Re: [fetchmail-devel] Re: RFC: Patch to fix Berlios Bug #5849

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

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

> Quoting from Matthias Andree's mail on Tue, Dec 13, 2005:
>> Sunil Shetye <sh...@bo...> writes:
>> 
>> > $ fetchmail -v --lmtp --smtphost localhost/port,/this/socket/is/up
>> >
>> > where localhost is indeed meant to be an LMTP server.
>> >
>> > The situation gets worse if fetchmail sends a bounce message in
>> > between!
>> 
>> One more thing: the whole LMTP implementation is a mess. Why would the
>> kind of socket (UNIX vs. INET) determine if SMTP or LMTP is spoken by
>> the service?
>
> It looks like it is assumed that there are no SMTP UNIX sockets.

Right, but my personal feeling is that a separate global --lmtp option
is plain ugly and undesirable, and LMTP hosts do not belong in
"--smtphost" for consistency reasons. 

I'd rather call this --mailsink (or perhaps, if someone has a better
name) and use tuples of {PROTOCOL}host/port, {PROTOCOL}[host]/port or
similar (delimiters around host similar to Postfix which goes out of the
IPv6 colon confusion when using :port).

PROTOCOL might default to SMTP if not given.

> I think, it is even more complex to give the port and type with every
> inet host and type with every unix socket. And there is no way of
> specifying different smtp options (esmtpname, esmtppassword) per
> smtphost.
>
> This should be a TODO.
>
> Any ideas, comments on this?

Yup, 6.4.0 stuff. This falls into a similar category as a hierarchical
rcfile parser with option inheritance. The current idea would be to
scope settings similar to C auto variables, and the result will then
resemble the ISC DHCP and ISC BIND configuration files.

I've added something to the TODO on the trunk.

-- 
Matthias Andree