Mailing List Archive

On Friday 24 August 2007 22:48, Benny Amorsen wrote:
> It would be very handy if Exim could try to deliver the mail (assuming
> it passed all checks) before actually accepting the mail in the
> incoming SMTP session. That way, errors like non-existent user would
> be relayed immediately to the original sender, making NDR's
> unnecessary.
>
> There are various practical problems with this suggestion, but do they
> make it useless in all cases?

Recipient callout verification takes care of nonexisting users (if no better
method is possible) as well as other errors that can be detected at RCPT
time. Later errors will result in an NDR, but to completely eliminate them
you will need to complete all deliveries, whether local or remote, before
returning an OK status. That can take a long time and would require a rather
fundamental redesign.

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans

On Fri, 24 Aug 2007, Magnus Holmgren wrote:

> Recipient callout verification takes care of nonexisting users (if no better
> method is possible) as well as other errors that can be detected at RCPT
> time. Later errors will result in an NDR, but to completely eliminate them
> you will need to complete all deliveries, whether local or remote, before
> returning an OK status. That can take a long time and would require a rather
> fundamental redesign.

Indeed. Remember that "a long time" might be days... The "better method"
referred to might be a shared database, LDAP or otherwise.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On Sat, Aug 25, 2007 at 10:02:38AM +0100, Philip Hazel wrote:
> > Recipient callout verification takes care of nonexisting users (if no better
> > method is possible) as well as other errors that can be detected at RCPT
> > time. Later errors will result in an NDR, but to completely eliminate them
> > you will need to complete all deliveries, whether local or remote, before
> > returning an OK status. That can take a long time and would require a rather
> > fundamental redesign.
>
> Indeed. Remember that "a long time" might be days... The "better method"
> referred to might be a shared database, LDAP or otherwise.

Clearly there are all sorts of gotchas as reasons why this doesn't work in all
cases: however, it would be nice if (thinking out loud):

If the message has exactly one recipient, and that recipient gets routed to an
'smtp' transport, then when smtp_data_acl returns 'accept', put the message on
the queue and attempt delivery immediately. If, within some specifiable
timeout (like the callout timeout options), the delivery attempt finishes,
then return accept/defer/deny to the connected SMTP client, and remove the
message from the queue. If the delivery attempt does not complete within that
period, presumably you'd have to return 'accept' to the SMTP client, and
continue the delivery attempt in the background: i.e. more or less normal
handling from then on.

Maybe the "only if routed to an smtp transport" requirement isn't necessary,
even.

/me likes wishing out loud :-)

--
Dave Evans
Power Internet Limited, registered in England #03053650 at Norfolk House,
82 Saxon Gate West, Central Milton Keynes, Buckinghamshire, MK9 2DL.
For more information, see http://www.powernet.co.uk/~davide/about-powernet

On Sat, 25 Aug 2007, Dave Evans wrote:

> Clearly there are all sorts of gotchas as reasons why this doesn't work in all
> cases: however, it would be nice if (thinking out loud):
>
> If the message has exactly one recipient, and that recipient gets routed to an
> 'smtp' transport,

Hold it right there. We are still in the SMTP input dialogue, right?
In that situation, Exim routes addresses in "verify" mode, not in
"delivery mode". So the result of routing might well be different. So we
have to build a new interface to re-run the routers in delivery mode,
just for this case.

> then when smtp_data_acl returns 'accept', put the message on
> the queue and attempt delivery immediately. If, within some specifiable
> timeout (like the callout timeout options), the delivery attempt finishes,
> then return accept/defer/deny to the connected SMTP client, and remove the
> message from the queue.

What do you do if the connection from the SMTP client has timed out in
the meantime? You'd have to remember the message id so that when the
client sends the message again, you don't try to deliver it again. If
lots of MTAs adopt this scheme, you may end up with a whole chain going
on... and all sorts of chaos might ensue.

> /me likes wishing out loud :-)

... but I fear there are nasty problems that require a more complicated
approach than just a small tinker.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On Tue, Aug 28, 2007 at 10:05:41AM +0100, Philip Hazel wrote:
> On Sat, 25 Aug 2007, Dave Evans wrote:
>
> > If the message has exactly one recipient, and that recipient gets routed to an
> > 'smtp' transport,
>
> Hold it right there. We are still in the SMTP input dialogue, right?
> In that situation, Exim routes addresses in "verify" mode, not in
> "delivery mode". So the result of routing might well be different. So we
> have to build a new interface to re-run the routers in delivery mode,
> just for this case.

As I said further down my post, the "and that recipient gets routed to an smtp
transport" bit is probably redundant; but yes, it would mean re-routing the
recipient in delivery mode, and checking that the result of that routing was
only one recipient (i.e. no multiple-child addresses).

> What do you do if the connection from the SMTP client has timed out in
> the meantime?

If your delivery attempt has not got as far as sending the end-of-message ".",
then abort the delivery (for remote smtp deliveries, that is). In fact it's
probably the same, even if you have sent the final ".". In some ways it's no
different from the existing problem: if the client sends "." and then
disconnects before receiving the response, there is the potential for
ambiguity.

> ... but I fear there are nasty problems that require a more complicated
> approach than just a small tinker.

No argument there!

--
Dave Evans
Power Internet Limited, registered in England #03053650 at Norfolk House,
82 Saxon Gate West, Central Milton Keynes, Buckinghamshire, MK9 2DL.
For more information, see http://www.powernet.co.uk/~davide/about-powernet