Duplicate mails part 2
Dear all
I have a problem according duplicate mail
since last discuss with weitse
http://www.mail-archive.com/postfix-users@postfix.org/msg34944.html
I would like to specify et dedicated transport maps in a master.cf
defined SMTP instance.
But it seems that the instance did not want to read the
transport_maps=hash:/etc/postfix/other.transport command line.
In this case when the smtp instance try to send the mail for
@test.example.com id did not find entries and return an error.
the question is ow to force the testsmtp instance to resolv
a new transport maps ?
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
recipient_bcc_maps = pcre:/etc/postfix/copy.pcre
/etc/postfix/transport:
test.example.comtestsmtp:
/etc/postfix/copy.pcre
/^(.*)@the\.example\.com$/ ${1}@test.example.com
/etc/postfix/master.cf:
testsmtp unix - - n - - smtp
-o smtp_generic_maps=pcre:/etc/postfix/testsmtp.pcre -o
transport_maps=hash:/etc/postfix/other.transport
/etc/postfix/testsmtp.pcre
/^(.*)@test\.example\.com$/ ${1}@example.com
/etc/postfix/other.transport
test.example.com smtp:[10.10.5.2]:25
Re: Duplicate mails part 2
David Touzeau:
>
> Dear all
>
> I have a problem according duplicate mail
> since last discuss with weitse
> http://www.mail-archive.com/postfix-users@postfix.org/msg34944.html
>
> I would like to specify et dedicated transport maps in a master.cf
> defined SMTP instance.
> But it seems that the instance did not want to read the
> transport_maps=hash:/etc/postfix/other.transport command line.
> In this case when the smtp instance try to send the mail for
> @test.example.com id did not find entries and return an error.
>
> the question is ow to force the testsmtp instance to resolv
> a new transport maps ?
transport_maps is used ONLY by the trivial-rewrite daemon.
To use different transport maps use multiple POSTFIX instances.
http://www.postfix.org/MULTI_INSTANCE_README.html
Wietse
>
> /etc/postfix/main.cf:
> transport_maps = hash:/etc/postfix/transport
> recipient_bcc_maps = pcre:/etc/postfix/copy.pcre
>
> /etc/postfix/transport:
> test.example.comtestsmtp:
>
> /etc/postfix/copy.pcre
> /^(.*)@the\.example\.com$/ ${1}@test.example.com
>
> /etc/postfix/master.cf:
> testsmtp unix - - n - - smtp
> -o smtp_generic_maps=pcre:/etc/postfix/testsmtp.pcre -o
> transport_maps=hash:/etc/postfix/other.transport
>
> /etc/postfix/testsmtp.pcre
> /^(.*)@test\.example\.com$/ ${1}@example.com
>
> /etc/postfix/other.transport
> test.example.com smtp:[10.10.5.2]:25
>
>
>
>
>
Re: Duplicate mails part 2
Le samedi 21 mai 2011 à 09:57 -0400, Wietse Venema a écrit :
> David Touzeau:
> >
> > Dear all
> >
> > I have a problem according duplicate mail
> > since last discuss with weitse
> > http://www.mail-archive.com/postfix-users@postfix.org/msg34944.html
> >
> > I would like to specify et dedicated transport maps in a master.cf
> > defined SMTP instance.
> > But it seems that the instance did not want to read the
> > transport_maps=hash:/etc/postfix/other.transport command line.
> > In this case when the smtp instance try to send the mail for
> > @test.example.com id did not find entries and return an error.
> >
> > the question is ow to force the testsmtp instance to resolv
> > a new transport maps ?
>
> transport_maps is used ONLY by the trivial-rewrite daemon.
> To use different transport maps use multiple POSTFIX instances.
> http://www.postfix.org/MULTI_INSTANCE_README.html
>
> Wietse
> >
> > /etc/postfix/main.cf:
> > transport_maps = hash:/etc/postfix/transport
> > recipient_bcc_maps = pcre:/etc/postfix/copy.pcre
> >
> > /etc/postfix/transport:
> > test.example.comtestsmtp:
> >
> > /etc/postfix/copy.pcre
> > /^(.*)@the\.example\.com$/ ${1}@test.example.com
> >
> > /etc/postfix/master.cf:
> > testsmtp unix - - n - - smtp
> > -o smtp_generic_maps=pcre:/etc/postfix/testsmtp.pcre -o
> > transport_maps=hash:/etc/postfix/other.transport
> >
> > /etc/postfix/testsmtp.pcre
> > /^(.*)@test\.example\.com$/ ${1}@example.com
> >
> > /etc/postfix/other.transport
> > test.example.com smtp:[10.10.5.2]:25
> >
> >
> >
> >
> >
>
Thanks wietse
postfix/forwarders and sender rewrite scheme
hi is there any recommended way to implement SRS (Sender Rewrite Scheme) in Postfix to get rid of SPF warnings/blocks for via "virtual_alias_maps" forwarded messages? status=sent (250 mail from IP 193.104.1.241 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [google.com]) ___ currently most forwarders are implmented this way, and yes the round(deliver_to) is needed because numeric targets are physical usermappings from dbmail and the limitation at the end is to make sure that multi-forwardings are handeled native by dbmail virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-forwarders.cf user = dbmailro password = * dbname = dbmail hosts= unix:/var/lib/mysql/mysql.sock inet:127.0.0.1:3307 query= select deliver_to from dbmail_aliases where alias='%u@%d' and round(deliver_to)=0 and (select count(*) from dbmail_aliases where alias='%u@%d')=1; -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
postfix not happy with libmysqlclient.so.18
8.2-RELEASE FreeBSD make && install done here: cat /usr/ports/mail/postfix-current/distinfo SHA256 (postfix/postfix-2.9-20110501.tar.gz) = 5789269f34fa152e39a70af3077f3ce4bc9c4e52fc67bb50a42e5d245ee1da3b SIZE (postfix/postfix-2.9-20110501.tar.gz) = 3671046 pkg_info shows: mysql-client-5.5.11 Multithreaded SQL database (client) mysql-server-5.5.9 Multithreaded SQL database (server) postfix-current-2.9.20110228,4 A secure alternative to widely-used Sendmail postconf /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, required by "postconf" locate libmysqlclient /usr/local/lib/mysql/libmysqlclient.a /usr/local/lib/mysql/libmysqlclient.so /usr/local/lib/mysql/libmysqlclient.so.18 /usr/local/lib/mysql/libmysqlclient_r.a /usr/local/lib/mysql/libmysqlclient_r.so /usr/local/lib/mysql/libmysqlclient_r.so.18 thanks Len
Re: postfix not happy with libmysqlclient.so.18
Am 21.05.2011 21:33, schrieb Len Conrad: > 8.2-RELEASE FreeBSD > > make && install done here: > > cat /usr/ports/mail/postfix-current/distinfo > SHA256 (postfix/postfix-2.9-20110501.tar.gz) = > 5789269f34fa152e39a70af3077f3ce4bc9c4e52fc67bb50a42e5d245ee1da3b > SIZE (postfix/postfix-2.9-20110501.tar.gz) = 3671046 > > > pkg_info shows: > > mysql-client-5.5.11 Multithreaded SQL database (client) > mysql-server-5.5.9 Multithreaded SQL database (server) > postfix-current-2.9.20110228,4 A secure alternative to widely-used Sendmail > > postconf > /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, > required by "postconf" > > locate libmysqlclient > /usr/local/lib/mysql/libmysqlclient.a > /usr/local/lib/mysql/libmysqlclient.so > /usr/local/lib/mysql/libmysqlclient.so.18 > /usr/local/lib/mysql/libmysqlclient_r.a > /usr/local/lib/mysql/libmysqlclient_r.so > /usr/local/lib/mysql/libmysqlclient_r.so.18 On FreeBSD, use one of the established ports management tools, notably, portmaster, or portupgrade. These ensure that your dependent ports are up to date, too. Also note that the locate database can be out of date and is not an authoritative reflection of what's really on your disks. To be sure, check the output of: find /usr/local -name libmysqlclient\* For shared library issues, running "ldconfig" can also help. -- Matthias Andree
Re: postfix not happy with libmysqlclient.so.18
Am 21.05.2011 21:33, schrieb Len Conrad: > 8.2-RELEASE FreeBSD > > make && install done here: > > cat /usr/ports/mail/postfix-current/distinfo > SHA256 (postfix/postfix-2.9-20110501.tar.gz) = > 5789269f34fa152e39a70af3077f3ce4bc9c4e52fc67bb50a42e5d245ee1da3b > SIZE (postfix/postfix-2.9-20110501.tar.gz) = 3671046 > > > pkg_info shows: > > mysql-client-5.5.11 Multithreaded SQL database (client) > mysql-server-5.5.9 Multithreaded SQL database (server) > postfix-current-2.9.20110228,4 A secure alternative to widely-used Sendmail > > postconf > /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, > required by "postconf" > > locate libmysqlclient > /usr/local/lib/mysql/libmysqlclient.a > /usr/local/lib/mysql/libmysqlclient.so > /usr/local/lib/mysql/libmysqlclient.so.18 > /usr/local/lib/mysql/libmysqlclient_r.a > /usr/local/lib/mysql/libmysqlclient_r.so > /usr/local/lib/mysql/libmysqlclient_r.so.18 this has nothing to do with postfix you or the package maintainer has simply to rebuild postfix and ALL other applications depending on mysql libraries anyways: your setup and/or the repos are borked because client/server should have the same version 5.5.9 and > 5.5.10 are NOT ABI-Comaptible bacause someone from oracle thought 5.5 is comatible with 5.1.x and they did not change the ABI-Version with the first 5.5.x releases http://dev.mysql.com/doc/refman/5.5/en/news-5-5-10.html signature.asc Description: OpenPGP digital signature
Re: postfix not happy with libmysqlclient.so.18
Also, be sure to double check you don't have a different Postfix installation in different paths, possibly with different PREFIX from past experiments. -- Matthias Andree
Re: postfix not happy with libmysqlclient.so.18
Len Conrad: > /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, > required by "postconf" This RUN-TIME LINER (NOT POSTFIX) error message says that your Postfix was built for a different library version. Wietse
Re: postfix not happy with libmysqlclient.so.18
On Sat, 2011-05-21 at 14:33:19 -0500, Len Conrad wrote: > 8.2-RELEASE FreeBSD > > make && install done here: > > cat /usr/ports/mail/postfix-current/distinfo > SHA256 (postfix/postfix-2.9-20110501.tar.gz) = > 5789269f34fa152e39a70af3077f3ce4bc9c4e52fc67bb50a42e5d245ee1da3b > SIZE (postfix/postfix-2.9-20110501.tar.gz) = 3671046 2.9-20110501 here. > pkg_info shows: > > mysql-client-5.5.11 Multithreaded SQL database (client) > mysql-server-5.5.9 Multithreaded SQL database (server) > postfix-current-2.9.20110228,4 A secure alternative to widely-used Sendmail 2.9.20110228 here. Make up your mind and only have one version installed. > postconf > /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, > required by "postconf" Woops. > locate libmysqlclient > /usr/local/lib/mysql/libmysqlclient.a > /usr/local/lib/mysql/libmysqlclient.so > /usr/local/lib/mysql/libmysqlclient.so.18 > /usr/local/lib/mysql/libmysqlclient_r.a > /usr/local/lib/mysql/libmysqlclient_r.so > /usr/local/lib/mysql/libmysqlclient_r.so.18 You upgraded MySQL; now rebuild Postfix to link to the new libs. -- Sahil Tandon
Custom message-id
Hi, I'm writing a report system and I want to identify the messages moving through my mail servers. I need this because I must save some headers and the first lines of the message in a database with the information from the log files. I think that the best way to relate the messages with the log lines is using the message-id but it has a problem. I can't trust in messages that arrive from the world. So what a want to do is to replace the message-id when every message arrives to our MXs and copy the original message-id to a second header. Message-id sometimes are useful to debug issues and I don't want to loose that information. Suggestions about how to do this? Regards, Diego -- Diego Woitasen
Re: Custom message-id
On 05/22/2011 03:46 AM, Diego Woitasen wrote: Hi, I'm writing a report system and I want to identify the messages moving through my mail servers. I need this because I must save some headers and the first lines of the message in a database with the information from the log files. I think that the best way to relate the messages with the log lines is using the message-id but it has a problem. I can't trust in messages that arrive from the world. So what a want to do is to replace the message-id when every message arrives to our MXs and copy the original message-id to a second header. Message-id sometimes are useful to debug issues and I don't want to loose that information. Suggestions about how to do this? Read http://www.postfix.org/header_checks.5.html on how to manipulate headers. The more complex case of dual actions you want may be better solved using milters, though: http://www.postfix.org/MILTER_README.html Can you explain why you need log information ? If you don't, simply piping all mail through an external processor will be the simplest way to extract information from it. This can be achieved in various ways, using recipient_bcc_maps or an smtp proxy. Regards, Diego -- Diego Woitasen -- J.
Re: Custom message-id
On Sat, May 21, 2011 at 10:59 PM, Jeroen Geilman wrote: > On 05/22/2011 03:46 AM, Diego Woitasen wrote: > >> Hi, >> I'm writing a report system and I want to identify the messages moving >> through my mail servers. I need this because I must save some headers and >> the first lines of the message in a database with the information from the >> log files. >> >> I think that the best way to relate the messages with the log lines is >> using the message-id but it has a problem. I can't trust in messages that >> arrive from the world. So what a want to do is to replace the message-id >> when every message arrives to our MXs and copy the original message-id to a >> second header. Message-id sometimes are useful to debug issues and I don't >> want to loose that information. >> >> Suggestions about how to do this? >> > > Read http://www.postfix.org/header_checks.5.html on how to manipulate > headers. > > The more complex case of dual actions you want may be better solved using > milters, though: > > http://www.postfix.org/MILTER_README.html > > Can you explain why you need log information ? > > If you don't, simply piping all mail through an external processor will be > the simplest way to extract information from it. > > This can be achieved in various ways, using recipient_bcc_maps or an smtp > proxy. > > >> Regards, >> Diego >> >> -- >> Diego Woitasen >> > > > -- > J. > > Thanks... Milter looks like the best option. I need to log all the information because I'm writing an audit system for a bank. The need all the information. The wanted to store every mail but that's obviusly impossible. The best thing that we can do is to store some headers and may be the first lines with the information provided in the log files. Regards, Diego -- Diego Woitasen
