Re: Hook into the Postfix sending process
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: 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
Re: Hook into the Postfix sending process
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 ;) 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: 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
Re: Hook into the Postfix sending process
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: 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: 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 > >
Re: Hook into the Postfix sending process
Is it possible to force postfix to create DSN for all categories (success,delay,fail) for every new mail? Tom On Jul 9, 2012, at 16:03 , Wietse Venema wrote: > 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: 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: 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 >> >>
Re: Hook into the Postfix sending process
Thomas Spycher: > Is it possible to force postfix to create DSN for all categories > (success,delay,fail) for every new mail? If you send multi-recipient messages, then you may receive one notification for the success-category recipients of that message, and one notification for the delayed-category or failed-category recipients (maybe the delayed and failed category are separate, too. I don't have time to dig through the code). Each report is in the same RFC-standardized form, so parsing this should be a no-brainer. In fact, remote MTAs that implement the same RFC standard will send you similar messages for delayed-category or failed-category recipients. But they should not send you notification for the success-category recipients if you configure Postfix as specified in my first response. Wietse > > On Jul 9, 2012, at 16:03 , Wietse Venema wrote: > > > 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: 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: 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 > >> > >> > >
SPF
This has probably been asked in the past, but is it worth it to go through the contortions to set up SPF? Thanks, Curtis
Re: SPF
Curtis Maurand: > This has probably been asked in the past, but is it worth it to go through > the contortions to set up SPF? Yes, if this is a recipient requirement. Wietse
Split multiple recipient mail
Hi, if Postfix receives an mail with multiple recipients (eg. to, cc and bcc). This mail gets processes as one single mail by postfix. How could it get accomplished to change the content of the mail for each recipient in an different way? Currently i've done this in an content filter. The Content filter gets the mail and does its stuff for each recipient and then requeues it again for each recipient. I would like to know, if there is an different way? An more postfix-like way? Greetings from Switzerland Tom
Re: SPF
Den 2012-07-09 17:20, Curtis Maurand skrev: This has probably been asked in the past, but is it worth it to go through the contortions to set up SPF? have you ever got bounces back from remote ip with your domain as envelope sender ? much better question that answers your question seen in dmarc some spammers use my domain in message-id and from: header, maybe just to test how bad spf is used ?
Re: SPF
Den 2012-07-09 17:44, Wietse Venema skrev: Curtis Maurand: This has probably been asked in the past, but is it worth it to go through the contortions to set up SPF? Yes, if this is a recipient requirement. why ?
not logging to syslog
Hi, I would like postfix to not log to the default syslog-daemon to have better control over where each specific postfix instance logs to. I am running multiple instances on a server. Postfix only knows about logging to syslog which is unfortunate, although I have read that someday postfix will change: Op 23/02/2010 om 09:18:29 -0500, schreef Wietse Venema: > At some point, the logging of Postfix will be configurable. It's > one of the first-generation pieces of code that is completely > hard-coded, as part of the drive to get a mail system released. Anyway, to separate the logs of each instance I could run almost all postfix services chrooted (/foo/bar) and then start a syslogd for each postfix instance listening in /foo/bar/dev/log Questions: - would this setup work? - would postfix still 'leak' messages to /dev/log? PS Wietse: +1 for this configurable logging subsystem -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services/NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ beh...@omroep.nl, 035-6773555 \/
Re: SPF
On 9 Jul 2012, at 11:20, Curtis Maurand wrote: This has probably been asked in the past, but is it worth it to go through the contortions to set up SPF? On the sending side, the simple answer is "YES!" There is a more complex and nuanced answer. There's a significant amount of misunderstanding about the benefits SPF actually will yield (not much, for most sending domains) and about the "contortions" required for it (again: for most domains a pragmatic SPF setup is trivial.) If you expect accurate SPF to make everyone always accept your valid mail, you will be disappointed. If you expect to be able to safely use a "-all" tail on a record for a domain that is used on legit mail, you stand a strong chance of disappointment. As for checking SPF on inbound mail, it has very narrow but potentially highly valuable uses. The original vision for SPF was that it would make SMTP envelope forgery more detectable, which is true for domains with SPF records but unfortunately SPF has a high potential for improperly identifying forgery. In addition, over the decade+ since SPF got started a significant subset of spammers have adopted practices that don't require envelope forgery. Where SPF checking can be useful is for use with specific domains that are heavily targeted by "phishing" mail, such as financial service providers and government agencies. This can require some "contortions" to deploy but if you already have flexible filtering in place such as SpamAssassin it can be rather simple. If your users get legit mail from phish-targeted domains you can get positive results by using SPF to "whitelist" the real stuff while generally treating mail claiming to be from those domains as suspect. For example, I managed filtering for a mail system where legit *@citigroup.com email was business critical but phishers were (at the time) throwing so much Citi-like junk at us that our adaptive filters would have persistently scored the legit mail as spam absent the SPF whitelisting. There is also a niche use of a pure "-all" SPF record that is a declaration that a domain is never used to send mail, but its value is minimal.
Re: SPF
Am 09.07.2012 19:00, schrieb Bill Cole: > On 9 Jul 2012, at 11:20, Curtis Maurand wrote: > >> This has probably been asked in the past, but is it worth it to go through >> the contortions to set up SPF? > > On the sending side, the simple answer is "YES!" > > There is a more complex and nuanced answer. There's a significant amount of > misunderstanding about the benefits SPF > actually will yield (not much, for most sending domains) and about the > "contortions" required for it (again: for > most domains a pragmatic SPF setup is trivial.) If you expect accurate SPF to > make everyone always accept your > valid mail, you will be disappointed. correct but it helps > If you expect to be able to safely use a "-all" tail on a record for a domain > that is used on legit mail, you stand a strong chance of disappointment why? each new mail-user get instructions how to configure his mail-client if he starts using the SMTP of his ISP against the instructions HOPEFULLY his mails get rejected - if all mail-admins/companies would act this way spammers life would be much harder to setup proepr PF/TXT records is plain easy if you control the nameservers and can be even fully automated [harry@srv-rhsoft:~]$ dig spf thelounge.net @8.8.8.8 ; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> spf thelounge.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24410 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;thelounge.net. IN SPF ;; ANSWER SECTION: thelounge.net. 86400 IN SPF "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all" [harry@srv-rhsoft:~]$ dig txt thelounge.net @8.8.8.8 ; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> txt thelounge.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52158 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;thelounge.net. IN TXT ;; ANSWER SECTION: thelounge.net. 86400 IN TXT "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all" signature.asc Description: OpenPGP digital signature
Re: SPF
Am 09.07.2012 18:30, schrieb Benny Pedersen: > Den 2012-07-09 17:20, Curtis Maurand skrev: >> This has probably been asked in the past, but is it worth it to go >> through the contortions to set up SPF? > > have you ever got bounces back from remote ip with your domain as > envelope sender ? > > much better question that answers your question > > seen in dmarc some spammers use my domain in message-id and from: > header, maybe just to test how bad spf is used ? > > > in real world setups it deeply depends what you want i have one domain with strict spf dkim an dmarc records this domain is heavy spammed but with less recipients all other domains have spf as test like hotmail also dkim but no special dmarc in dns i.e hotmail.com.3600IN TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" strict spf has its problems with mail lists by breaking forward so this may rise your users support, but its good to have it in testing mode for income check at big mailers, also it helps little on backscatter you should always use dkim this days ( see it faqs ) dmarc is kind of overhead to spf and dkim, again read its faqs by what you want, recent i found no big advantage with dmarc, but this must not be the same at your side at income check i do spf only selective on some domains on a few servers, also there are many broken spf dns setups outside so its up to you ,choose what fits to your needs -- Best Regards MfG Robert Schetterer
Re: not logging to syslog
Leo Baltus: > Hi, > > I would like postfix to not log to the default syslog-daemon to > have better control over where each specific postfix instance logs to. I > am running multiple instances on a server. Postfix has syslog_facility to split different syslog streams. Otherwise propose a new syslog API and get everyone to adopt it. Wietse
Re: SPF
Am 09.07.2012 19:43, schrieb Robert Schetterer: > strict spf has its problems with mail lists by breaking forward > so this may rise your users support, but its good to have > it in testing mode for income check at big mailers, also it helps little > on backscatter mailinglists are not the problem envelope: owner-postfix-us...@postfix.org the real problem are users which wants forwarding to a foreign external address and are unable to disable SPF checks there or misconfigured destinations with SPF check on the final-destination while not exclude their own filter-machine in front of signature.asc Description: OpenPGP digital signature
Re: not logging to syslog
Am 09.07.2012 19:52, schrieb Wietse Venema: > Leo Baltus: >> Hi, >> >> I would like postfix to not log to the default syslog-daemon to >> have better control over where each specific postfix instance logs to. I >> am running multiple instances on a server. > > Postfix has syslog_facility to split different syslog streams. > Otherwise propose a new syslog API and get everyone to adopt it no need :-) he could simply configure his syslog daemon proper that is why it exists rsyslog: :msg, contains, "whatever" -/var/log/whatever :msg, contains, "whatever" ~ at the very begin of the rules or a sample i am using to have dhcp not in /var/log/messages: :programname, isequal, "dhcpd" -/var/log/dhcpd.log :programname, isequal, "dhcpd" ~ signature.asc Description: OpenPGP digital signature
Re: SPF
On 9 Jul 2012, at 13:15, Reindl Harald wrote: Am 09.07.2012 19:00, schrieb Bill Cole: On 9 Jul 2012, at 11:20, Curtis Maurand wrote: This has probably been asked in the past, but is it worth it to go through the contortions to set up SPF? On the sending side, the simple answer is "YES!" There is a more complex and nuanced answer. There's a significant amount of misunderstanding about the benefits SPF actually will yield (not much, for most sending domains) and about the "contortions" required for it (again: for most domains a pragmatic SPF setup is trivial.) If you expect accurate SPF to make everyone always accept your valid mail, you will be disappointed. correct but it helps If you expect to be able to safely use a "-all" tail on a record for a domain that is used on legit mail, you stand a strong chance of disappointment why? (1) There are many perfectly innocent systems that allow traditional transparent forwarding (i.e. as with aliases or .forward files) from local addresses to arbitrary external addresses. Some domains (including some belonging to professional and university alumni organizations) have large numbers of users but no local delivery at all, merely acting as forwarders without touching the envelope sender of mail they handle. (2) There are well-meaning services (including major newspaper websites) which send surrogate mail for their users with the users' email address as the envelope sender. (3) There are receiving systems that treat a SPF "hard fail" result as an absolute or near-absolute basis for rejection of mail. As a result, it is common for people to send to a forwarded address unknowingly or to click a "mail this page to a friend" link on a website and generate a situation in a final SMTP hop that cannot affirmatively pass any SPF check (except with a simple "+all" record, which would be pointless.) If you want to make a stand on aspirational principles for all of your users that transparent forwarding is bad and surrogate mail should carry an envelope sender of the surrogate in all cases, and you are willing to have some mail that your users want to send or to have sent on their behalf fail, then using a "-all" tail on a SPF record might be good and proper for your domain. The freedom to make such a quixotic stand is uncommon for mail systems with more than a few score users.
Re: SPF
Am 09.07.2012 20:25, schrieb Bill Cole: > On 9 Jul 2012, at 13:15, Reindl Harald wrote: >>> If you expect to be able to safely use a "-all" tail on a record for a >>> domain >>> that is used on legit mail, you stand a strong chance of disappointment >> >> why? > > (1) There are many perfectly innocent systems that allow traditional > transparent forwarding (i.e. as with aliases > or .forward files) from local addresses to arbitrary external addresses. Some > domains (including some belonging to > professional and university alumni organizations) have large numbers of users > but no local delivery at all, merely > acting as forwarders without touching the envelope sender of mail they handle. so the user is resposible that his destination server is not rejecting mails from the forwarding server > (2) There are well-meaning services (including major newspaper websites) > which send surrogate mail for their users > with the users' email address as the envelope sender. they are doing it simply wrong > (3) There are receiving systems that treat a SPF "hard fail" result as an > absolute or near-absolute basis for > rejection of mail. sad that not all are doing this > As a result, it is common for people to send to a forwarded address > unknowingly or to click a "mail this page to a > friend" link on a website and generate a situation in a final SMTP hop that > cannot affirmatively pass any SPF check > (except with a simple "+all" record, which would be pointless.) as said: this services are doing it wrong any wbeservice MUST NOT use a random foreign domain as sender these days > If you want to make a stand on aspirational principles for all of your users > that transparent forwarding is bad and > surrogate mail should carry an envelope sender of the surrogate in all cases, > and you are willing to have some mail > that your users want to send or to have sent on their behalf fail, then using > a "-all" tail on a SPF record might > be good and proper for your domain. The freedom to make such a quixotic stand > is uncommon for mail systems with > more than a few score users. and because too many people agrue this way resulting in a lot of spam with forged envelope-senders becasue too few domains wiht SPF records signature.asc Description: OpenPGP digital signature
Re: SPF
Am 09.07.2012 20:03, schrieb Reindl Harald: > > > Am 09.07.2012 19:43, schrieb Robert Schetterer: >> strict spf has its problems with mail lists by breaking forward >> so this may rise your users support, but its good to have >> it in testing mode for income check at big mailers, also it helps little >> on backscatter > > mailinglists are not the problem > envelope: owner-postfix-us...@postfix.org > > the real problem are users which wants forwarding > to a foreign external address and are unable to > disable SPF checks there or misconfigured destinations > with SPF check on the final-destination while not exclude > their own filter-machine in front of > Hi Harald, thx for your debug, but my intention was to short problems that may happen with strict spf , not a detailed tec analysis cause you never will know whats going on exactly in the wild -- Best Regards MfG Robert Schetterer
Re: SPF
On 7/9/2012 2:44 PM, Reindl Harald wrote: > > Am 09.07.2012 20:25, schrieb Bill Cole: >> On 9 Jul 2012, at 13:15, Reindl Harald wrote: If you expect to be able to safely use a "-all" tail on a record for a domain that is used on legit mail, you stand a strong chance of disappointment >>> why? >> (1) There are many perfectly innocent systems that allow traditional >> transparent forwarding (i.e. as with aliases >> or .forward files) from local addresses to arbitrary external addresses. >> Some domains (including some belonging to >> professional and university alumni organizations) have large numbers of >> users but no local delivery at all, merely >> acting as forwarders without touching the envelope sender of mail they >> handle. > so the user is resposible that his destination server is > not rejecting mails from the forwarding server > >> (2) There are well-meaning services (including major newspaper websites) >> which send surrogate mail for their users >> with the users' email address as the envelope sender. > they are doing it simply wrong > >> (3) There are receiving systems that treat a SPF "hard fail" result as an >> absolute or near-absolute basis for >> rejection of mail. > sad that not all are doing this > >> As a result, it is common for people to send to a forwarded address >> unknowingly or to click a "mail this page to a >> friend" link on a website and generate a situation in a final SMTP hop that >> cannot affirmatively pass any SPF check >> (except with a simple "+all" record, which would be pointless.) > as said: this services are doing it wrong > > any wbeservice MUST NOT use a random foreign domain as sender these days > >> If you want to make a stand on aspirational principles for all of your users >> that transparent forwarding is bad and >> surrogate mail should carry an envelope sender of the surrogate in all >> cases, and you are willing to have some mail >> that your users want to send or to have sent on their behalf fail, then >> using a "-all" tail on a SPF record might >> be good and proper for your domain. The freedom to make such a quixotic >> stand is uncommon for mail systems with >> more than a few score users. > and because too many people agrue this way resulting in a lot of spam > with forged envelope-senders becasue too few domains wiht SPF records > +1 on all points. -Vinny
Re: got local delivery where there should be delivery via dovecot to virtual mbox
On Sun, 08 Jul 2012 21:16:19 -0500 Noel Jones wrote: > On 7/8/2012 4:18 PM, Stan Hoeppner wrote: > > On 7/8/2012 3:20 PM, Christopher J. Ruwe wrote: > > > >> Jul 8 22:09:28 mail postfix/local[1999]: 144761410: > >> to=, relay=local, delay=0.97, > >> delays=0.54/0.03/0/0.4, dsn=5.1.1, status=bounced (unknown user: > >> "test") > > > > By default, for local delivery, Postfix looks up user names in the > > system database. It won't query your virtual database. You've not > > added a UNIX system account nor alias of "test". This is why this > > fails. > > > >> That is were I was before. How can I, without having a named to > >> nameserve proper domains, change main.cf to reflect that I am, in > >> fact, catering mail for muellerbackwaren.local as $mydomain? > > > > When specifying $mydomain you are specifying local delivery, hence > > "postfix/local" above. The solution should be as simple as: > > > > 1. Creating local system users, or simply not using $mydomain, and > > sticking with all virtual delivery > > > > 2. If you must use $mydomain, tell Postfix that local deliveries > > are supposed to go to Dovecot by adding to main.cf: > > > > mailbox_command = /usr/lib/dovecot/deliver > > > > alternately, you can set > # main.cf > mydestination = localhost > > > -- Noel Jones Thank you very much, this solved my problem. Thanks, cheers -- Christopher J. Ruwe TZ: GMT + 2h signature.asc Description: PGP signature
Re: got local delivery where there should be delivery via dovecot to virtual mbox
On Sun, 8 Jul 2012 18:07:59 -0400 (EDT) Wietse Venema wrote: > Christopher J. Ruwe: > > Jul 8 22:09:28 mail postfix/local[1999]: 144761410: > > to=, relay=local, delay=0.97, > > delays=0.54/0.03/0/0.4, dsn=5.1.1, status=bounced (unknown user: > > "test") > > > > That is were I was before. How can I, without having a named to > > nameserve proper domains, change main.cf to reflect that I am, in > > fact, catering mail for muellerbackwaren.local as $mydomain? > > You have configured Postfix to deliver mail for muellerbackwaren.local > with the Postfix local delivery agent, which delivers mail for UNIX > system accounts. > > You achieved this by listing muellerbackwaren.local in > main.cf:mydestination. > > If you do not want this mail to go to the Postfix local delivery > agent, then do not list muellerbackwaren.local in cf:mydestination. > Instead, list the domain in the appropriate address class, as > specified in http://www.postfix.org/ADDRESS_CLASS_README.html. > > Wietse Thank you very much for your help .. I did as Noe Jones suggested to solve my issue. I think that the doc you pointed me at will prove instuctive beyond my little problem. Thanks for helping me understand. -- Christopher TZ: GMT + 2h signature.asc Description: PGP signature
Re: Split multiple recipient mail
On 07/09/2012 05:47 PM, Thomas Spycher wrote:
Hi,
if Postfix receives an mail with multiple recipients (eg. to, cc and bcc). This
mail gets processes as one single mail by postfix.
Only on reception; when it is queued, the message is duplicated as many
times as necessary to address all next-hop destinations.
How could it get accomplished to change the content of the mail for each
recipient in an different way?
The MTA is really the wrong place to manipulate message content - but
it's ultimately up to you.
Currently i've done this in an content filter. The Content filter gets the mail
and does its stuff for each recipient and then requeues it again for each
recipient.
Sounds like you've solved it, then.
I would like to know, if there is an different way? An more postfix-like way?
Since you're *changing the message for each recipient*, they must be
split up into separate messages.
It doesn't really matter how you do that.
I would probably opt to make it a fully controllable process by first
queueing and re-injecting it into a second listener or postfix instance
by utilizing ${second-smtpd}_recipient_limit = 1
This forces all multi-recipient mail to be split up before it reaches
your content filter, thus simplifying the overall design.
--
J.
Re: Split multiple recipient mail
On Tue, Jul 10, 2012 at 12:45:34AM +0200, Jeroen Geilman wrote:
> I would probably opt to make it a fully controllable process by
> first queueing and re-injecting it into a second listener or postfix
> instance by utilizing ${second-smtpd}_recipient_limit = 1
Right idea, wrong implementation. A better solution is to set the
_destination_recipient = 1
where is the name of the dedicated transport used to
feed messages into the content_filter. For example:
main.cf:
content_filter = cf_smtp
cf_smtp_destination_recipient_limit = 1
master.cf:
cf_smtp unix ... smtp
--
Viktor.
