Feature request: delay smtpd client connection response until queue item is removed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Feature request: delay smtpd client connection response until queue item is removed

Maarten Vanraes
Hey,

Normal smtpd client connection handling (after DATA) would be "Queued as
XXXX".

I would like to request a feature where the smtpd response is delayed
until the mail is completely actually handled (ie: removed from queue)
(of course not by default).

It would be (for example) only for trusted networks and be configured
with something like this:
  * smtpd_delay_data_response = yes
  * smtpd_max_delay_data_response = 60 (seconds)
  * some parameters to limit this for specific connections (eg: client
connections or sender classes or similar)

The smtpd would then reply like this:
  * Timed out while waiting for queue processing(queued as XXXXXXX)
  * status = sent (delivered to [hidden email], queued as XXXXXXX)
  * status = bounced .....

--
BA NV
IT & Security

Bezoek ons op 22 en 23 maart op INFOSECURITY, STORAGE EXPO & TOOLING
EVENT 2017!
Registreer via http://ba.be/infosec en je krijgt je gratis toegangsbadge
toegestuurd.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: delay smtpd client connection response until queue item is removed

Noel Jones-2
On 3/28/2017 3:40 AM, Maarten Vanraes wrote:
> Hey,
>
> Normal smtpd client connection handling (after DATA) would be
> "Queued as XXXX".
>
> I would like to request a feature where the smtpd response is
> delayed until the mail is completely actually handled (ie: removed
> from queue) (of course not by default).
>

Mail is a store-and-forward protocol. Postfix replies with the
Queued response when the message is safely stored in the queue.

You're asking for a proxy that doesn't reply until the mail is
passed on to a further destination.

There are several SMTP proxies available if you search google, and
postfix has a smtpd_proxy_filter option which is usually used as a
front end for content inspection proxy.  That may or may not suit
your needs.
http://www.postfix.org/SMTPD_PROXY_README.html#config

If you describe the actual problem you're trying to solve, there may
be other options.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: delay smtpd client connection response until queue item is removed

Viktor Dukhovni
In reply to this post by Maarten Vanraes

> On Mar 28, 2017, at 4:40 AM, Maarten Vanraes <[hidden email]> wrote:
>
> The smtpd would then reply like this:
> * Timed out while waiting for queue processing(queued as XXXXXXX)
> * status = sent (delivered to [hidden email], queued as XXXXXXX)
> * status = bounced .....

With SMTP this is architecturally not possible for multi-recipient
mail.  A single message may require multiple downstream deliveries
and some may succeed while others tempfail or hardfail.  With alias
expansion this can even happen for what is initially a single-recipient
message.

This also seems like a rather bad idea.  Instead, use the DSN NOTIFY
ESMTP extension, which is the right wait to be notified of delivery
completion and status.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feature request: delay smtpd client connection response until queue item is removed

Wietse Venema
In reply to this post by Maarten Vanraes
Maarten Vanraes:
> Hey,
>
> Normal smtpd client connection handling (after DATA) would be "Queued as
> XXXX".
>
> I would like to request a feature where the smtpd response is delayed
> until the mail is completely actually handled (ie: removed from queue)
                                                    ^^^^^^^^^^^^^^^^^^^^
I looked at a system that tried to do that that before Postfix was
released, and found that it was broken by design. It got into trouble
when one message had recipients in different domains, and some of
those were down.

        Wietse
Loading...