run external command when new mail arrives
Hi there, I need an external command to be run whenever new mail is finally delivered to a virtual domain, but I don't need access to the body of that mail, only who it is for (from its headers). Just wondering if content filtering is the most efficient way supported by Postfix to do that: http://www.postfix.org/FILTER_README.html Thanks.
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Tue, Oct 20, 2009 at 01:03:04PM +0500, rihad wrote: Hi there, I need an external command to be run whenever new mail is finally delivered to a virtual domain, but I don't need access to the body of that mail, only who it is for (from its headers). Just wondering if content filtering is the most efficient way supported by Postfix to do that: http://www.postfix.org/FILTER_README.html "Who it is for" cannot be derived from headers, only "who it appears to be for". You need the RCPT TO information. This is available for a content filter, but a policy daemon would probably be more efficient for your case: http://www.postfix.org/SMTPD_POLICY_README.html Yup, sorry, wrong wording, I knew that To: was under sender's control, and is often forged. Thanks, I'll look into that.
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Tue, Oct 20, 2009 at 01:03:04PM +0500, rihad wrote: Hi there, I need an external command to be run whenever new mail is finally delivered to a virtual domain, but I don't need access to the body of that mail, only who it is for (from its headers). Just wondering if content filtering is the most efficient way supported by Postfix to do that: http://www.postfix.org/FILTER_README.html "Who it is for" cannot be derived from headers, only "who it appears to be for". You need the RCPT TO information. This is available for a content filter, but a policy daemon would probably be more efficient for your case: http://www.postfix.org/SMTPD_POLICY_README.html "The Postfix SMTP server has a number of built-in mechanisms to block or accept mail at specific SMTP protocol stages." But the mail could later be filtered etc., so it's a bit early for the external program to run. I want it to run only if the delivery has been guaranteed, like as the last content filter through pipe. Nevermind the body overhead. Possible?
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Tue, Oct 20, 2009 at 02:04:15PM +0500, rihad wrote: "The Postfix SMTP server has a number of built-in mechanisms to block or accept mail at specific SMTP protocol stages." But the mail could later be filtered etc., so it's a bit early for the external program to run. I want it to run only if the delivery has been guaranteed, like as the last content filter through pipe. Nevermind the body overhead. Possible? You could replace the virtual(8) delivery agent by a program of your own, by adding an entry in master.cf and pointing "virtual_transport" to it. http://www.postfix.org/postconf.5.html#virtual_transport http://www.postfix.org/master.5.html Aha, and then if I'd like the original executable to do its work, _without_ having read the body, will exec'ing it be enough? #!/bin/sh # do my own actions with respect to RCPT TO ... exec /path/to/postfix/virtual $@ And should I expect that multiple addresses in RCPT TO are possible? I'm afraid that if I use virtual_destination_recipient_limit = 1 performance will suffer.
Re: run external command when new mail arrives
Wietse Venema wrote: rihad: Geert Hendrickx wrote: On Tue, Oct 20, 2009 at 02:04:15PM +0500, rihad wrote: "The Postfix SMTP server has a number of built-in mechanisms to block or accept mail at specific SMTP protocol stages." But the mail could later be filtered etc., so it's a bit early for the external program to run. I want it to run only if the delivery has been guaranteed, like as the last content filter through pipe. Nevermind the body overhead. Possible? You could replace the virtual(8) delivery agent by a program of your own, by adding an entry in master.cf and pointing "virtual_transport" to it. http://www.postfix.org/postconf.5.html#virtual_transport http://www.postfix.org/master.5.html Aha, and then if I'd like the original executable to do its work, _without_ having read the body, will exec'ing it be enough? You MUST use one of Postfix's deliver programs in master.cf: local, virtual, pipe, smtp. The interface to the queue manager is not published and is subject to change without notice. Programs that depend on Postfix internals are unsupported and will break with the next release. Bad. Then I guess content filtering (being last in the chain) is the only way to go for me.
Re: run external command when new mail arrives
Wietse Venema wrote: rihad: Aha, and then if I'd like the original executable to do its work, _without_ having read the body, will exec'ing it be enough? You MUST use one of Postfix's deliver programs in master.cf: local, virtual, pipe, smtp. The interface to the queue manager is not published and is subject to change without notice. Programs that depend on Postfix internals are unsupported and will break with the next release. Bad. Then I guess content filtering (being last in the chain) is the only way to go for me. You have three options as far as filtering goes: 1) While mail is received (http://www.postfix.org/SMTPD_PROXY_README.html) 2) After the mail is received (http://www.postfix.org/FILTER_README.html) 3) While mail is delivered (with local(8, a shell command in ~/.forward, or with pipe(8), a parametrized shell command). Number 3) is the way to go. Does .forward work with virtual domains? If not, then I guess we come back to pipe(8). All I need is to run a command based on the RCPT TO (send SMS).
Re: run external command when new mail arrives
Robert Schetterer wrote: Geert Hendrickx schrieb: On Tue, Oct 20, 2009 at 02:04:15PM +0500, rihad wrote: "The Postfix SMTP server has a number of built-in mechanisms to block or accept mail at specific SMTP protocol stages." But the mail could later be filtered etc., so it's a bit early for the external program to run. I want it to run only if the delivery has been guaranteed, like as the last content filter through pipe. Nevermind the body overhead. Possible? You could replace the virtual(8) delivery agent by a program of your own, by adding an entry in master.cf and pointing "virtual_transport" to it. http://www.postfix.org/postconf.5.html#virtual_transport http://www.postfix.org/master.5.html Geert maildrop has good possibilities to exec external progs If I understood Wietse correctly, You MUST use one of Postfix's deliver programs in master.cf: local, virtual, pipe, smtp. as the interface to the queue manager is not published and is subject to change without notice. I might as well write my own thin wrapper for virtual and be done: #!/bin/sh # do not read the body, but do my own actions based on RCPT TO ... # and finally... exec /path/to/postfix/virtual $@ and change in master.cf: virtual unix - n n - - /path/to/my/virtual-wrapper
Re: run external command when new mail arrives
Wietse Venema wrote:
rihad:
Aha, and then if I'd like the original executable to do its work,
_without_ having read the body, will exec'ing it be enough?
You MUST use one of Postfix's deliver programs in master.cf:
local, virtual, pipe, smtp.
The interface to the queue manager is not published and is subject
to change without notice. Programs that depend on Postfix internals
are unsupported and will break with the next release.
Bad. Then I guess content filtering (being last in the chain) is the
only way to go for me.
You have three options as far as filtering goes:
1) While mail is received (http://www.postfix.org/SMTPD_PROXY_README.html)
2) After the mail is received (http://www.postfix.org/FILTER_README.html)
3) While mail is delivered (with local(8, a shell command in
~/.forward, or with pipe(8), a parametrized shell command).
Ours is a mass-mail hosting solution with virtual(8), so local(8) and
~/.forward can't be used? pipe(8) is the only option I guess. Given this
maildrop example in master.cf (we're not using maildrop):
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
could someone please say how I'd configure external program myprog
instead of maildrop? Maybe something like:
myprog unix - n n - - pipe
user=vmail argv=/path/to/myprog -d ${recipient}
myprog will only do something based on ${recipient}, and will ignore the
message itself. What would I put in main.cf to activate the execution of
this program for each email delivered by virtual(8) without affecting
other aspects of the current working system? I'm not very much familiar
with Postfix.
Thanks a lot.
Re: run external command when new mail arrives
Geert Hendrickx wrote:
On Tue, Oct 20, 2009 at 10:57:58PM +0500, rihad wrote:
could someone please say how I'd configure external program myprog
instead of maildrop? Maybe something like:
myprog unix - n n - - pipe
user=vmail argv=/path/to/myprog -d ${recipient}
myprog will only do something based on ${recipient}, and will ignore
the message itself. What would I put in main.cf to activate the
execution of this program for each email delivered by virtual(8)
without affecting other aspects of the current working system? I'm
not very much familiar with Postfix.
"virtual_transport = myprog" in main.cf (default is "virtual"), if you
define "myprog" in master.cf like you described.
Optionally set myprog_destination_recipient_limit = 1 or other limitations
your program might need. Look for transport_* settings in postconf(5), you
can all override them for "myprog" specifically with myprog_*.
Very interesting why Wietse said that
You MUST use one of Postfix's deliver programs in master.cf:
local, virtual, pipe, smtp.
The interface to the queue manager is not published and is subject
to change without notice. Programs that depend on Postfix internals
are unsupported and will break with the next release.
But then:
Maildrop can be invoked that way.
What's so special about maildrop? If there's no published interface for
Postfix's internals, then maildrop could as easily break with Postfix's
next release, couldn't it?
Re: run external command when new mail arrives
Geert Hendrickx wrote:
On Tue, Oct 20, 2009 at 10:57:58PM +0500, rihad wrote:
could someone please say how I'd configure external program myprog
instead of maildrop? Maybe something like:
myprog unix - n n - - pipe
user=vmail argv=/path/to/myprog -d ${recipient}
myprog will only do something based on ${recipient}, and will ignore
the message itself. What would I put in main.cf to activate the
execution of this program for each email delivered by virtual(8)
without affecting other aspects of the current working system? I'm
not very much familiar with Postfix.
"virtual_transport = myprog" in main.cf (default is "virtual"), if you
define "myprog" in master.cf like you described.
Optionally set myprog_destination_recipient_limit = 1 or other limitations
your program might need. Look for transport_* settings in postconf(5), you
can all override them for "myprog" specifically with myprog_*.
One more thing, please: after myprog has done its job, how can I pass
the original message back to postfix so it does whatever should be done
after myprog is finished (like delivering the message with virtual(8))?
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Wed, Oct 21, 2009 at 10:20:50AM +0500, rihad wrote: One more thing, please: after myprog has done its job, how can I pass the original message back to postfix so it does whatever should be done after myprog is finished (like delivering the message with virtual(8))? Pass it to maildrop? :-) We aren't using maildrop, but virtual(8). So, if I do virtual_transport = myprog # set up in master.cf via pipe # all remaining old virtual_* settings remaining untouched # ... in the myprog shell script, after it has done its job, how to pass control to virtual(8)? Something like echo "OK virtual"? You're talking to a postfix newbie facing too close a deadline, please bear with me ;-)
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Wed, Oct 21, 2009 at 11:04:44AM +0500, rihad wrote: in the myprog shell script, after it has done its job, how to pass control to virtual(8)? Something like echo "OK virtual"? You're talking to a postfix newbie facing too close a deadline, please bear with me ;-) You can't. Postfix has a limited set of documented interfaces between Postfix internal processes and external processes. "pipe" is one of them, "virtual" is not. Once postfix hands off the mail to "pipe", it's in your hands. In your case (SMS notifications) however, I would keep things simple and not try to integrate it so tightly into the delivery process, but just fork your incoming mails to two transports: "virtual" for actual delivery (handled by Postfix) and your own transport for the SMS notifications. You can do this with virtual aliases: f...@yourdomain.net f...@yourdomain.net f...@sms.yourdomain.net b...@yourdomain.net b...@yourdomain.net b...@sms.yourdomain.net ... This is so repetitive. All our alias maps are in mysql, and there's an app behind them which isn't under my control, so... Can I rewrite whole domains? Like this: @yourdomain.net @yourdomain.net @sms.yourdomain.net
Re: run external command when new mail arrives
Geert Hendrickx wrote: On Wed, Oct 21, 2009 at 06:52:21PM +0500, rihad wrote: Geert Hendrickx wrote: In your case (SMS notifications) however, I would keep things simple and not try to integrate it so tightly into the delivery process, but just fork your incoming mails to two transports: "virtual" for actual delivery (handled by Postfix) and your own transport for the SMS notifications. You can do this with virtual aliases: f...@yourdomain.net f...@yourdomain.net f...@sms.yourdomain.net b...@yourdomain.net b...@yourdomain.net b...@sms.yourdomain.net ... This is so repetitive. All our alias maps are in mysql, and there's an app behind them which isn't under my control, so... Can I rewrite whole domains? Like this: @yourdomain.net @yourdomain.net @sms.yourdomain.net That will break recipient validation. However, with MySQL, you should be able to put the duplication of addresses in the query or in the result filter? We have two maps: virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-maps.cf virtual_maps = mysql:/etc/postfix/mysql-virtual.cf /etc/postfix/mysql-virtual-maps.cf: user = postfix password = c00lpass dbname = mail table = users select_field = maildir where_field = email additional_conditions = and enabled = 1 hosts = 127.0.0.1 /etc/postfix/mysql-virtual.cf user = postfix password = c00lpass dbname = mail table = alias select_field = goto where_field = address hosts = 127.0.0.1 the first table definitely does recipient validation, as well as getting their maildir. The latter table has a few important aliases, like info@, support@, etc going to the real person's email. Which setting should I tweak? I'm lost, the docs are overwhelming for a newb like myself :-(
Re: run external command when new mail arrives
rihad wrote:
We have two maps:
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-maps.cf
virtual_maps = mysql:/etc/postfix/mysql-virtual.cf
/etc/postfix/mysql-virtual-maps.cf:
user = postfix
password = c00lpass
dbname = mail
table = users
select_field = maildir
where_field = email
additional_conditions = and enabled = 1
hosts = 127.0.0.1
/etc/postfix/mysql-virtual.cf
user = postfix
password = c00lpass
dbname = mail
table = alias
select_field = goto
where_field = address
hosts = 127.0.0.1
the first table definitely does recipient validation, as well as getting
their maildir. The latter table has a few important aliases, like info@,
support@, etc going to the real person's email.
Which setting should I tweak? I'm lost, the docs are overwhelming for a
newb like myself :-(
OK here's how far I've gone:
master.cf:
smsnotif unix - n n - - pipe
flags=DRhu user=vmail argv=/root/smsnotif ${recipient}
/root/smsnotif:
#!/bin/sh
echo "$@" >> /tmp/smsnotif.log
(and of course chmod +x /root/smsnotif)
main.cf:
virtual_maps = mysql:/etc/postfix/mysql-virtual.cf
mysql:/etc/postfix/mysql-virtual-smsnotif.cf
transport_maps = mysql:/etc/postfix/mysql-transport.cf
/etc/postfix/mysql-virtual.cf:
user = postfix
password = blahblah
dbname = mail
hosts = 127.0.0.1
query = select coalesce(goto,email) from users left join alias on
(email=address) where email='%s'
/etc/postfix/mysql-virtual-smsnotif.cf:
user = postfix
password = blahblah
dbname = mail
hosts = 127.0.0.1
query = select replace(coalesce(goto, email), '@', '@sms.') from users
left join alias on (email=address) where email='%s'
/etc/postfix/mysql-transport.cf:
user = postfix
password = blahblah
dbname = mail
table = transport
select_field = transport
where_field = domain
hosts = 127.0.0.1
mysql> select * from transport;
+--+---+--+
| domain | transport | desc |
+--+---+--+
| example.com | virtual | NULL |
| sms.example.com | smsnotif | NULL |
so virtual_maps will normally end up as u...@example.com +
u...@sms.example.com.
Now when I send email with the command "sendmail -v u...@example.com"
the mail _does_ make it into u...@example.com's maildir using
virtual(8), but the /root/smsnotif isn't even called (the logfile isn't
created).
What did I forget?
Re: run external command when new mail arrives
Magnus Bäck wrote:
On Wednesday, October 21, 2009 at 19:43 CEST,
rihad wrote:
OK here's how far I've gone:
master.cf:
smsnotif unix - n n - - pipe
flags=DRhu user=vmail argv=/root/smsnotif ${recipient}
/root/smsnotif:
#!/bin/sh
echo "$@" >> /tmp/smsnotif.log
(and of course chmod +x /root/smsnotif)
main.cf:
virtual_maps = mysql:/etc/postfix/mysql-virtual.cf
mysql:/etc/postfix/mysql-virtual-smsnotif.cf
transport_maps = mysql:/etc/postfix/mysql-transport.cf
/etc/postfix/mysql-virtual.cf:
user = postfix
password = blahblah
dbname = mail
hosts = 127.0.0.1
query = select coalesce(goto,email) from users left join alias on
(email=address) where email='%s'
/etc/postfix/mysql-virtual-smsnotif.cf:
user = postfix
password = blahblah
dbname = mail
hosts = 127.0.0.1
query = select replace(coalesce(goto, email), '@', '@sms.') from users
left join alias on (email=address) where email='%s'
No, that's not how things work. With
virtual_alias_maps = A, B
Postfix will only consult B if A doesn't provide any results. You need
to return all addresses in a single lookup result.
Finally everything's working now! Thank you very much. I promise, I
_will_ read all of the online documentation from the start.
Hint: Does the vmail user have access to the /root directory?
Indeed, under CentOS /root is disallowed any access from anyone except
root, but this was easy to spot in the logs once I've fixed table lookup.
There was no such user as vmail in the system either. I had thought that
if these examples are uncommented in master.cf, then the user is
probably there. But neither was the user, nor maildrop was installed
(which I don't need anyway) ;-)
Re: run external command when new mail arrives
Wietse Venema wrote:
You forgot to test the virtual alias expansion.
postmap -q u...@example.com mysql:/etc/postfix/mysql-virtual.cf
Thus should produce the same result as a hash: table with:
u...@example.comu...@example.com, u...@sms.example.com
Ditto for the transport map.
Now that I've fixed table lookup following from Magnus' advice, all is
working!
# postmap -q ri...@example.com mysql:/etc/postfix/mysql-virtual.cf
ri...@example.com,ri...@sms.example.com
The query now looks like this:
query = select coalesce(goto,email),replace(coalesce(goto,email), '@',
'@sms.') from users left join alias on (email=address) where email='%s'
I know it's not the best query out there, but since we do not allow @
signs in user names ("local part"), the problem is impractical.
Re: run external command when new mail arrives
rihad wrote:
Now that I've fixed table lookup following from Magnus' advice, all is
working!
# postmap -q ri...@example.com mysql:/etc/postfix/mysql-virtual.cf
ri...@example.com,ri...@sms.example.com
The query now looks like this:
query = select coalesce(goto,email),replace(coalesce(goto,email), '@',
'@sms.') from users left join alias on (email=address) where email='%s'
I know it's not the best query out there, but since we do not allow @
signs in user names ("local part"), the problem is impractical.
Now for the second question. sms.ourdomain.com isn't in our DNS (only
ourdomain.com is), but still someone might like it to send email
directly to our SMTP to u...@sms.ourdomain.com. How can I disallow that?
I want @sms.ourdomain.com to be only available internally to Postfix
itself. Currently we have:
mydestination = localhost, $myhostname, localhost.$mydomain,
mysql:/etc/postfix/mysql-mydestination.cf
/etc/postfix/mysql-mydestination.cf:
user = postfix
password = blahblah
dbname = mail
table = transport
select_field = domain
where_field = domain
hosts = 127.0.0.1
mysql> select domain from transport;
+---+
| domain|
+---+
| sms.ourdomain.com |
| ourdomain.com |
Skip bouncing messages
Hi, all. Can Postfix 2.8 be configured to skip generating bounce messages in case there was a problem delivering the message? Sometimes we need to send messages to our subscribers through phplist from a legitimate address, and we aren't really interested in getting the bounces delivered to that address. Thanks.
Re: Skip bouncing messages
On 01/04/2012 03:29 PM, Robert Schetterer wrote: Am 04.01.2012 12:01, schrieb rihad: Hi, all. Can Postfix 2.8 be configured to skip generating bounce messages in case there was a problem delivering the message? Sometimes we need to send messages to our subscribers through phplist from a legitimate address, and we aren't really interested in getting the bounces delivered to that address. Thanks. Bad idea, bounces are tec infos if you get bounces you should update your address list to avoid them in future if you wont do so, you will have a good chance to get blacklistet sometimes somewhere cause of sending unwanted/unneeded mail Yeah, we know the risks. Can it be done?
Re: Skip bouncing messages
On 01/04/2012 04:44 PM, Jeroen Geilman wrote: On 2012-01-04 12:01, rihad wrote: Hi, all. Can Postfix 2.8 be configured to skip generating bounce messages in case there was a problem delivering the message? Sometimes we need to send messages to our subscribers through phplist from a legitimate address, and we aren't really interested in getting the bounces delivered to that address. Thanks. Mail sent from or through a mailing list manager should have a bounce address set that can be processed by the mailing list manager. "We're not interested in delivering bounce messages" sounds like you're spamming. Well, not in the broad sense, they're all our customers with registered email addresses. The From field is an info@ address that people may reply to. Apparently it can't be allocated to the mailing list software. So there's no way to turn bouncing off? I don't mind doing it globally. We're using Postfix MTA for that simple task only.
storing mydestination in mysql
Hi there, I'm a Postfix newb playing with Postfix-current under FreeBSD and am now trying to store mydestination in mysql: /usr/local/etc/postfix/main.cf: mydestination = mysql:/usr/local/etc/postfix/mysql-mydestination.conf /user/local/etc/postfix/mysql-mydestination.conf: host = localhost username = postfix password = none dbname = mail expansion_limit = 1 query = SELECT v FROM mydestination WHERE k='%s' table mail.mydestination: mysql> show create table mydestination; +---+-+ | Table | Create Table | +---+-+ | mydestination | CREATE TABLE `mydestination` ( `k` varchar(255) NOT NULL, `v` varchar(255) DEFAULT NULL, PRIMARY KEY (`k`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | +---+-+ 1 row in set (0.01 sec) mysql> select * from mydestination; +-+--+ | k | v| +-+--+ | $myhostname | NULL | +-+--+ 1 row in set (0.01 sec) mysql> Rationale (taken from mysql_table(5)): LIST MEMBERSHIP When using SQL to store lists such as $mynetworks, $mydestination, $relay_domains, $local_recipient_maps, etc., it is important to under- stand that the table must store each list member as a separate key. The table lookup verifies the *existence* of the key. See "Postfix lists versus tables" in the DATABASE_README document for a discussion. Do NOT create tables that return the full list of domains in $mydesti- nation or $relay_domains etc., or IP addresses in $mynetworks. DO create tables with each matching item as a key and with an arbitrary value. Alas, restarting Postfix shows no queries being tried in MySQL query log, and "postconf mydestination" simply greps whatever's in main.cf: $ postconf mydestination mydestination = mysql:/usr/local/etc/postfix/mysql-mydestination.conf $ What's going on? How is Postfix supposed to learn the whole mydestination list if there's no such SQL template? I thought Postfix would deduce a "select k from mydestination" query or similar on its own. The manpage is ambiguous in this regard. Thanks.
Re: storing mydestination in mysql
Correction: /usr/local/etc/postfix/main.cf: mydestination = mysql:/usr/local/etc/postfix/mysql-mydestination.conf /user/local/etc/postfix/mysql-mydestination.conf: host = localhost username = postfix password = none dbname = mail expansion_limit = 1 query = SELECT v FROM mydestination WHERE k='%s' I had a couple of brain farts when writing the above (incorrect host, username specification)... This is the correct mysql-mydestination.conf but the problem still persists: hosts = localhost user = postfix password = none dbname = mail expansion_limit = 1 query = SELECT v FROM mydestination WHERE k='%s'
Re: storing mydestination in mysql
mouss wrote: rihad wrote: query = SELECT v FROM mydestination WHERE k='%s' - do not return NULL. since the result is unused, simply use query = SELECT 'blah' mydestination WHERE k='%s' Sorry, but your suggested fix doesn't solve the problem: the query still doesn't happen when I restart Postfix. > - '$myhostname' will never match because a domain name does not start > with '$'. and no, mysql won't expand that for you. Thanks, I thought querying mysql was like querying any other information provider, be it literal lists in main.cf, where $myhostname _is_ allowed. I will replace $myhostname in MySQL with its expanded value once I get the query to happen at all...
Re: storing mydestination in mysql
rihad wrote: What's going on? How is Postfix supposed to learn the whole mydestination list if there's no such SQL template? I thought Postfix would deduce a "select k from mydestination" query or similar on its own. The manpage is ambiguous in this regard. Answering to myself: OK, Postfix seems to wish to learn mydestination "lazily", that is, it issues SQL queries only when receiving mail to decide what to do with it. Lack of the way to choose to cache query results is pretty surprising. Moreover, a simple telnet to SMTP port and then issuing RCPT TO: [EMAIL PROTECTED] results in _4_ successive queries every time! SELECT 1 FROM mydestination WHERE k='bar.com'
Re: storing mydestination in mysql
mouss wrote:
rihad wrote:
rihad wrote:
What's going on? How is Postfix supposed to learn the whole
mydestination list if there's no such SQL template? I thought Postfix
would deduce a "select k from mydestination" query or similar on its
own. The manpage is ambiguous in this regard.
Answering to myself: OK, Postfix seems to wish to learn mydestination
"lazily", that is, it issues SQL queries only when receiving mail to
decide what to do with it.
of course! postfix will not load a mysql table in memory. if it were so,
then this would be useless: you could simply dump the sql tables before
into a file ;-p
Sure enough, but I'm speaking of a single snapshotted value through a
single request ("transaction"). Besides its being more efficient,
caching makes for more consistent results: you wouldn't want Postfix to
first consider a delivery local (mydestination), only to suddenly change
its opinion and consider it remote. I hope it wouldn't dump core in that
case :)
Lack of the way to choose to cache query results is pretty surprising.
Moreover, a simple telnet to SMTP port and then issuing RCPT TO:
[EMAIL PROTECTED] results in _4_ successive queries every time!
run
# postconf | egrep "(mydestination|parent_dom)"
you'll need to read about lookup order and about mysql table.
consider using proxymap (proxy:mysql:)
Oh, now you see what I meant by caching. Thanks, I haven't read about
proxymap yet, and I will.
Anyway, it is generally not recommended to put domain lists
(mydestination, relay_domains, virtual_*_domains), transport and
relocated maps in a remote backend.
If MySQL is local it's just a matter of convenience. I agree that remote
MySQL brings in yet another point of failure.
Re: storing mydestination in mysql
Victor Duchovni wrote:
On Wed, Sep 17, 2008 at 08:51:48PM +0500, rihad wrote:
Sure enough, but I'm speaking of a single snapshotted value through a
single request ("transaction"). Besides its being more efficient,
caching makes for more consistent results: you wouldn't want Postfix to
first consider a delivery local (mydestination), only to suddenly change
its opinion and consider it remote.
Actually, you would want it to route correctly, based on the state of
the world at the time message delivery is attempted.
Sure, but every (retrial) attempt is a _different_ "transaction"! I was
speaking of a setting remaining the same within a _single_ attempt
(fractions of a second or more), which it doesn't, given that Postfix
test 4 times if @domain belongs to mydestination.
Postfix is *not* monolothic, and message delivery is not instantaneous.
Messages may sit in queues long enough to see the routing topology or
domain address classes change. This is fine.
Of course, and all those attempts are different transactions, as I
called them, so it's start afresh every time.
Re: storing mydestination in mysql
rihad wrote: mouss wrote: Also set parent_domain_matches_subdomains = (empty) Then retry to see how many lookups there are. [snip] But it's different processes doing the queries (one to accept the message, one to route the message to the local delivery agent, ...). Oh, in that case it's OK. Correcting myself once again: It's not OK :) I forgot to mention that all those 4 requests were the result of me issuing RCPT TO alone. I can't see how message acceptance or routing are involved.
Domain name appended despite remote_header_rewrite_domain being empty
Hi there, I'm a Postfix newb playing my way with FreeBSD 7 port named postfix-current-2.6.20080814,4. In http://www.postfix.org/ADDRESS_REWRITING_README.html it says that: Postfix never rewrites message header addresses from remote SMTP clients when the remote_header_rewrite_domain parameter value is empty (the default setting). Nevertheless when I connect to Postfix SMTP from another machine and attempt to relay through it, mail eventually arrives with domain name appended: [EMAIL PROTECTED]:~$ telnet nigar 25 Trying 192.168.0.248... Connected to nigar.localnet. Escape character is '^]'. 220 nigar.localnet ESMTP Postfix mail from: foo 250 2.1.0 Ok rcpt to: [EMAIL PROTECTED] 250 2.1.5 Ok data 354 End data with . Subject: hi fi . 250 2.0.0 Ok: queued as 7F5EB2EC4E quit 221 2.0.0 Bye Connection closed by foreign host. that is both From: and Return-Path: headers contain [EMAIL PROTECTED] and not just foo. local_header_rewrite_clients presumably only applies to local connections: local_header_rewrite_clients = permit_inet_interfaces remote_header_rewrite_domain = myhostname = nigar.localnet mydomain = localnet mynetworks_style = subnet Have I misinterpreted the docs? Why is @nigar.localnet being appended for email being relayed? Thanks.
Re: storing mydestination in mysql
Victor Duchovni wrote: On Wed, Sep 17, 2008 at 10:09:53PM +0500, rihad wrote: Correcting myself once again: It's not OK :) I forgot to mention that all those 4 requests were the result of me issuing RCPT TO alone. I can't see how message acceptance or routing are involved. You are wasting everyone's time with this line of inquiry. Postfix makes the queries it needs to make. Focusing too closely on that is not productive. The SQL query cost is not generally performance limiting, and tuning the low-cost operations is not productive. That's your opinion. My opinion is that one query should be made, the rest should be cached throughout the end of processing for consistency's sake (let's forget about performance for a moment). If you want the fewest possible lookups against $mydestination, get $mydestination out of $relay_domains (backwards compatible, but no longer optimal default). relay_domains was and is empty (please see one of my last replies to mouss). After that stop counting queries, it is not a good use of anyone's time. It's just something for Postfix devs to think about, not necessarily you.
Re: storing mydestination in mysql
mouss wrote: rihad wrote: Victor Duchovni wrote: If you want the fewest possible lookups against $mydestination, get $mydestination out of $relay_domains (backwards compatible, but no longer optimal default). relay_domains was and is empty (please see one of my last replies to mouss). While I trust Viktor, he doesn't have access to my mailbox ;-p Ok, you win :) I wasn't paying attention and most of my replies to you weren't cc'd to [EMAIL PROTECTED] My apologies. So now we all have enough evidence that I had set relay_domains to empty. After that stop counting queries, it is not a good use of anyone's time. It's just something for Postfix devs to think about, not necessarily you. and you're saying this to Viktor? Sorry, but isn't Postfix written by W. Venema? Or maybe Mr. Victor is a contributor, as some of us are?
Re: storing mydestination in mysql
rihad wrote: Victor Sorry again, I meant Viktor.
virtual_mailbox_maps w/out massive tables?
This is probably a faq, but still... I've been playing with virtual delivery: main.cf: virtual_mailbox_domains = bar.com virtual_mailbox_base = /home/massmail virtual_mailbox_maps = regexp:/usr/local/etc/postfix/home.map virtual_minimum_uid = 1002 virtual_uid_maps = static:1002 virtual_gid_maps = static:1002 home.map: /^(.+)@([EMAIL PROTECTED])$/$2/$1/ [EMAIL PROTECTED]:~$ telnet nigar smtp Trying 192.168.0.248... Connected to nigar.localnet. Escape character is '^]'. 220 nigar.localnet ESMTP Postfix mail from: rihad 250 2.1.0 Ok rcpt to: [EMAIL PROTECTED] 250 2.1.5 Ok data 354 End data with . Subject: hi five . 250 2.0.0 Ok: queued as 82F692F459 quit 221 2.0.0 Bye Connection closed by foreign host. /var/log/maillog: Sep 23 19:59:58 nigar postfix/virtual[2077]: warning: regexp map /usr/local/etc/postfix/home.map, line 1: regular expression substitution is not allowed: skipping this rule Sep 23 19:59:58 nigar postfix/virtual[2077]: 82F692F459: to=<[EMAIL PROTECTED]>, relay=virtual, delay=7.5, delays=7.4/0.04/0/0.06, dsn=5.1.1, status=bounced (unknown user: "[EMAIL PROTECTED]") username > homedir mapping is pretty static in its nature. How can I still do it without silly large data tables? Thanks.
Re: virtual_mailbox_maps w/out massive tables?
mouss wrote: rihad wrote: This is probably a faq, but still... I've been playing with virtual delivery: main.cf: virtual_mailbox_domains = bar.com virtual_mailbox_base = /home/massmail virtual_mailbox_maps = regexp:/usr/local/etc/postfix/home.map virtual_minimum_uid = 1002 virtual_uid_maps = static:1002 virtual_gid_maps = static:1002 home.map: /^(.+)@([EMAIL PROTECTED])$/$2/$1/ when you have it working, remind me to send mail to <../../../../tmp/@bar.com> :) Agreed :) This is just alpha version, for getting to know Postfix. Still I thought virtual_mailbox_base was as smart as it looked like? qmail for example disallows .. in paths. username > homedir mapping is pretty static in its nature. How can I still do it without silly large data tables? You need a "silly large data table" because you need to only accept mail to valid addresses. with your wildcard setup, all addresses are valid. Aha, in the strive for getting regexp: to work I haven't yet thought any further. Of course you're right. So, ... if you really want to accept all mail, then "break" recipient validation (a wildcard virtual alias is enough) and use maildrop, dovecot or procmail to do the actual delivery. but you'll have to check the recipient address to avoid random stuff in your filesystem. any of these alternative delivery methods aren't required to get simple things going.
