Re: [fetchmail-devel] RFC: support --smtphost for bounces

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

On Wed, 21 Feb 2007, Sunil Shetye wrote:

> Quoting from Matthias Andree's mail on Mon, Feb 19, 2007:
> > how about the attached patch to fix the "bounces are always
> > SMTP-injected to localhost without regard to the --smtphost"?
> > <http://bugs.debian.org/150137>
> > 
> > It's not perfect, and I don't know how to handle cases where --smtphost
> > contains LMTP hosts exclusively or is switched to LMTP by --lmtp -
> > suggestions?
> 
> A lot more work will be required for this.
> 
> Here I am assuming that smtphost is not localhost and requires
> authentication for relaying the bounce message. The code currently
> does not do that because localhost (by default) allows relaying of the
> bounce message without authentication.

> For using smtphost as a relay server for the bounce message, fetchmail
> will have to authenticate using esmtpname. For that, fetchmail will
> have to send EHLO, save the response, and parse it. For that, separate
> structure will have to be maintained per smtp connection. All the smtp
> variables which are currently global/static will have to be part of
> that structure.

It's not clear to me this is required at all sites (Postfix's mynetworks
and permit_mynetworks allows IP-based relaying as in "my local networks
are allowed to" out of the box), but at least esmtpname should be
supported indeed.

Perhaps the whole SMTP engine needs to be made thread-safe and reentrant
at application level so that we don't have to reimplement things as it's
now with two SMTP clients.

BTW, I've recently received a report (openSUSE) where the user complained
bitterly he lost mail after his localhost SMTP listener had refused every
SMTP command (including RSET!!!) with a 500 series code, because there
was no TLS in use and bouncing was disabled, so fetchmail just went
ahead and deleted the message.
<https://bugzilla.novell.com/show_bug.cgi?id=246829>

> There will also be a compatibility problem if the user has not
> specified any esmtpname. This is not a problem for the incoming mail
> as the mail is (presumably) being delivered locally on the smtphost.
> However, for the bounce message, authentication is a must as the
> smtphost is now going to act as a relay server. So, smtphost should be
> automatically used only if the user has specified an esmtpname.

The automatisms that are going to hide underneath such logic scare me,
we'll get dozens of "why does it not care about smtphost, I don't need
to login to SMTP" questions.

Perhaps the easiest is backing out the change and deferring the solution
to 6.4 and leave this bug in 6.3. I'm somewhat pushing forward to start
the 6.4 cycle since the 6.3 bug arrival rate has decreased and there are
some larger changes I'd like to make, and leave 6.3 for security fixes
and critical regression fixes rather sooner than later so we can make
some progress (requiring change in behavior) towards the goals, one of
them should be consistency...

Best,

-- 
Matthias Andree