Thomas Spycher:
> Hi Wiets
>
> That sounds like exactly the solution i was looking for just at
> an unexpected location :) I'll give it a try!
>
> I could send the status notification mails to the mta back and
> filter them in my milter script and taataaa i have the status of
> the delivered mail. Sounds perfect, at least in theory ;)
If you like you can provide each message with your own unique
identifier (called envelope ID).
Command-line: sendmail -V envelope-id ...
SMTP: MAIL FROM:<sender> ENVID=envelope-id
Or you can ask Postfix to provide non-repeating queue IDs
(with "enable_long_queue_ids = yes" in main.cf).
The relevant RFCs are:
RFC 3461 (SMTP DSN extension)
RFC 3462 (Delivery Status Notifications)
RFC 3463 (Enhanced status codes)
RFC 3464 (Delivery Status Notifications)
Wietse
> Thanks Tom
>
> On Jul 9, 2012, at 12:50 , Wietse Venema wrote:
>
> > Thomas Spycher:
> >> So my questions are:
> >>
> >> 1. Can anyone explain me how the original smtp binary takes
> >> commands from the queue?
> >
> > That is an internal interface. Programs that depend on this are NOT
> > SUPPORTED and WILL BREAK as Postfix evolves over time.
> >
> > To catch delivery status, submit mail with SUCCESS,DELAY,FAIL status
> > notification requested.
> >
> > $ sendmail -N success,delay,fail
> >
> > RCPT TO:<example> NOTIFY=SUCCESS,DELAY,FAIL
> >
> > Then, have Postfix report SUCCESS, DELAY or FAIL as mail leaves
> > your perimeter (or is delayed, or rejected):
> >
> > /etc/postfix/main.cf:
> > # The following makes DELAY notification work.
> > delay_warning_time = 1s
> > # The following makes SUCCESS notification work.
> > smtp_discard_ehlo_keywords = dsn
> >
> > This will give you an RFC-compliant status report; the "delay" report
> > will probably be separate.
> >
> > Wietse
>
>
