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 > >