Re: no route to host
* Stan Hoeppner [2012-07-30 14:35]: > On 7/29/2012 6:57 PM, Engin qwert wrote: > > > Actually it is not router. It is only BPL modem. After Static IP hiring the > > ISP send me an email how to configure the server with this IP addresses > > information. The 10.138.9.201 internal IP address selection was not made by > > myself. > > Engin what country are you in? Who is your ISP? > > A year or two ago I was assisting someone on teh Debian list, who is in > a former Soviet block Eastern European country, can't recall now which > one. RIPE was apparently screwing small ISPs over in these countries > and not giving them the netblocks they needed. Hello, RIPE is screwing noone over. RIPE has clearly defined rules that apply if you request network blocks. So if they didn't get network blocks they clearly didn't have the right documentation/reasons for it. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Failover gateway server
Hello, We are setting up a gateway server (mx.example.com) to serve as primary MX (for domain example.com). It will receive mail from the Internet and forward (relay) it using: transport_maps = hash:/etc/postfix/transportmap where: /etc/postfix/transportmap example.com relay:[mail.example.com] I was wondering whether we could set up this server in a way so it can forward (relay) all mail to mail.example.com AND, if (and only if) this is temporarily down, then: 1. Keep incoming mail in queue until it can contact mail.example.com again and deliver. (Does this happen by default?) - AND - 2. Relay incoming mail *also* to mail2.example.com (that is, only for the period when mail.example.com is down). Can we set this up (and how)? The idea is to provide a mailbox for users where they can access the mail arriving for them during the period when their main mailbox is down for some reason. The rest of time, the "secondary" mailbox on mail2.example.com would be auto sync'ed to the "primary" (normal) one, on mail.example.com, using some other process. (e.g. using dovecot dsync.) Please advise. Thanks in advance, Nick
Re: Failover gateway server
On Tue, Aug 07, 2012 at 03:24:37PM +0300, Nikolaos Milas wrote: > I was wondering whether we could set up this server in a way so it > can forward (relay) all mail to mail.example.com AND, if (and only > if) this is temporarily down, then: > > 1. Keep incoming mail in queue until it can contact mail.example.com > again and deliver. (Does this happen by default?) By default mail delivery will be retried for up to 5 days. > - AND - > 2. Relay incoming mail *also* to mail2.example.com (that is, only > for the period when mail.example.com is down). This is difficult to automate reliably, what you can do instead is arrange to be notified that the primary is down and you decide whether/when to update the transport table to route all mail to the backup mailhub (make sure the primary stays down and just in case also 'postfix reload" after the transport change so that the active queue is reloaded). # : shutdown switch port of primary ... # : update the transport table ... # postmap transport; : unless an SQL or LDAP table, ... # postfix reload # postfix flush The SMTP delivery agent has a very narrow view of the failure of the primary relay, it switching over when a single message is deferred would be a really bad idea. Likewise, the queue manager may defer the destination if the primary takes a couple of minutes to reboot, but this too would be a bad reason to make a switch. You need to make a deliberate choice to notify your users and cut-over to the secondary system. There are other alternatives that provide storage replication at either the block, file-system or IMAP layer, allowing multiple relays to deliver to "the same" highly available mailbox. This can be a hot-cold or a hot-hot HA solution, and detailes vary greatly. -- Viktor.
always_bcc
Hi there, I'm trying to implement always_bcc to send a copy of all received messages to another server. My idea is disable any notification messages back in the second server (if something goes wrong) and discard all messages after received. This way is like the "clean" solution to ensure that the always_bcc destination never bounces or refuses a message. It seems weird , but is only a test that I need to do. 1st problem: aways_bcc is not working. 2nd problem: I have no idea how to disable notification messages. My main.cf: http://dpaste.com/782638/ My master.cf: http://dpaste.com/782639/ Thank you.
Re: mysql query suppressed?
email builder: > I read in http://www.postfix.org/mysql_table.5.html for the %d > substitution in the query if the lookup is not a full email address > with domain, the entire query is not even executed? Is this right? If postfix does not work as documented, please post a bug report. Wietse
RE: no route to host
Hi, there. The problem has solved by itself or maybe the ISP has made a change or an improvement due to my request after you captured that the problem is the "router or upstream". Thank you for your great support, and sparing me your valuable time. Engin YILMAZ
error when using procmail to forward message
Hello, I setup procmail. I have a system wide config: LOGFILE=/var/log/procmail.log VERBOSE=on :0B: * (://[A-Za-z0-9.-]+\.ru) /dev/null :0: * ^Subject: (Rolex) /dev/null :0 * ^Subject: (anoncvs) ! m...@server1.com some...@server2.com I checked the log and it is putting spam in /dev/null, but there are errors in procmail.log when ever it tries to forward the emails: sendmail: warning: the Postfix sendmail command has set-uid root file permissions sendmail: warning: or the command is run from a set-uid root process sendmail: warning: the Postfix sendmail command must be installed without set-uid root file permissions Is there a way to fix this? Best Regards, Al
strange behaviours with sender_dependent_default_transport_maps
Hello let me explains Reading the manual, it explain that sender_dependent_default_transport_maps override default_transport first I want to white-list sender address allow to sender mail to other domain so fisrt I did that in main.cf default_transport = error:error message sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependent_default_transport_maps with /etc/postfix/sender_dependent_default_transport_maps containing postmas...@domain.com smtp: In this case all my sender get the error then I try in main.cf default_transport = smtp: sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependent_default_transport_maps with /etc/postfix/sender_dependent_default_transport_maps containing postmas...@domain.com error:message_1 It work like expected if sender is postmas...@domain.com i get the error with message_1 and all other sender can send mail to finish i try in main.cf default_transport = error:message_2 sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependent_default_transport_maps with /etc/postfix/sender_dependent_default_transport_maps containing postmas...@domain.com error:message_1 all user sending message get message_2 So what I understand is if the default transport is set to error the postfix override it whit the sender_dependent_default_transport_maps value Don't know if it is a bug or me that miss something Thanks
Re: strange behaviours with sender_dependent_default_transport_maps
On Tue, Aug 07, 2012 at 05:51:43PM +0200, zorg wrote: > Reading the manual, it explain that > sender_dependent_default_transport_maps override default_transport Which selects the delivery agent and nexthop for *external* recipients based on the sender. This is NOT an access control mechanism. > first I want to white-list sender address allow to sender mail to > other domain You're abusing the feature as an access control mechanism. Don't do that. http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html -- Viktor.
Best way to protect backup-mx?
Hi list, I'm currently doing some brainstorming on how to protect backup-mx servers from being directly contacted by clients. I found that postscreen can do this, but as far as I read only if the backup runs on the same machine. Another idea that came in my mind is that the backup-mx checks the postgrey status of the main-mx and rejects clients that have no record in master's postgrey. But this seems for me not very accurate. The only clear case would be if postgrey has no record for the client or does not answer at all because the entire server is down/having problems. But how to react on backup if the client has a record in masters postgrey? Or one could write a script for backup-mx that upon receiving mail tries to contact master and check if a testmail could be sent. If the testmail could be sent to master, then drop the connection from client on backup Somehow I have no idea what the "best" approach would be. Thanks a lot for any input/hints/tips tobi
Re: Best way to protect backup-mx?
On Tue, Aug 7, 2012 at 9:45 AM, tobi wrote: > Hi list, > > I'm currently doing some brainstorming on how to protect backup-mx > servers from being directly contacted by clients. Why would you want to protect your clients from your backup mx?
Re: error when using procmail to forward message
On 2012-08-07 Al Zick wrote: > I setup procmail. I have a system wide config: > > LOGFILE=/var/log/procmail.log > VERBOSE=on > > :0B: > * (://[A-Za-z0-9.-]+\.ru) > /dev/null > > :0: > * ^Subject: (Rolex) > /dev/null > > :0 > * ^Subject: (anoncvs) > ! m...@server1.com some...@server2.com > > I checked the log and it is putting spam in /dev/null, but there are > errors in procmail.log when ever it tries to forward the emails: > > sendmail: warning: the Postfix sendmail command has set-uid root file > permissions > sendmail: warning: or the command is run from a set-uid root process > sendmail: warning: the Postfix sendmail command must be installed > without set-uid root file permissions These are warnings, not errors. > Is there a way to fix this? chmod u-s /usr/sbin/sendmail Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: Best way to protect backup-mx?
On 2012-08-07 tobi wrote: > I'm currently doing some brainstorming on how to protect backup-mx > servers from being directly contacted by clients. That kinda defeats the purpose of having a backup MX in the first place. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: Best way to protect backup-mx?
On 8/7/2012 11:45 AM, tobi wrote: > Hi list, > > I'm currently doing some brainstorming on how to protect backup-mx > servers from being directly contacted by clients. I found that > postscreen can do this, but as far as I read only if the backup runs on > the same machine. > Another idea that came in my mind is that the backup-mx checks the > postgrey status of the main-mx and rejects clients that have no record > in master's postgrey. But this seems for me not very accurate. The only > clear case would be if postgrey has no record for the client or does not > answer at all because the entire server is down/having problems. But how > to react on backup if the client has a record in masters postgrey? > Or one could write a script for backup-mx that upon receiving mail tries > to contact master and check if a testmail could be sent. If the testmail > could be sent to master, then drop the connection from client on backup > Somehow I have no idea what the "best" approach would be. > > Thanks a lot for any input/hints/tips The first thing you need to do is define for us what "protect backup-mx servers" means. What, exactly, do you want to protect them from? -- Stan
Re: mysql query suppressed?
- Original Message - > From: Wietse Venema > To: Postfix users > Cc: > Sent: Tuesday, August 7, 2012 8:26 AM > Subject: Re: mysql query suppressed? > > email builder: >> I read in http://www.postfix.org/mysql_table.5.html for the %d >> substitution in the query if the lookup is not a full email address >> with domain, the entire query is not even executed? Is this right? > > If postfix does not work as documented, please post a bug report. I'm really not sure - what I'm asking for is clarification of the documentation. To me, it says if you use "%d" in your query and the lookup key is not in the form of "u...@domain.tld" (ie local part only), then the query is "suppressed". Does that mean I can't do a query that tests if "%d" is NULL and return a result accordingly? My initial tests seem to indicate that my suspicion is correct, but I'm not expert enough so I was asking for help in this matter.
Re: Mapping one domain to another (mysql)
>> Probably the best lesson to learn from postfixadmin is: you can have
>> more than one lookup table in postfix per main.cf directive.
>> Postfixadmin uses 2 separate queries for "regular" aliases and
>> domain
>> aliases.
>>
>> from main.cf:
>> virtual_alias_maps = /etc/postfix/mysql_virtual_alias_maps.cf
>> /etc/postfix/virtual_alias_domain_maps.cf
>>
>> where each file contains a simple db query. Makes it much easier to
>> write the correct query, on the expense of some more db load.
>
> Thanks Tom for making it more clear.
>
> However, if you split to two queries, you still need a complex query for the
> mapped domain. In my example, still like:
>
> query = select if ('%d' = 'example-2.com', IFNULL((select dest
> from aliases where addr = '%u...@example.com'), (select addr from users
> where addr = '%u...@example.com')), NULL)
>
> I've found that in conjunction with a 2nd query (the original normal one),
> everything seems to work as expected (including aliases with only local parts
> like "postmaster")
>
> But I'm still unsure if this kind of query is correct, if I'm on the
> right track. Can anyone tell me if there's a better way to do it?
>
> Where are all those examples that are supposedly posted on this list
> previously?
Bump - surely there's someone out there who has done this and can tell me if
the kind of query above is either misguided or approximately what is needed to
achieve this feature.
ie, Do I really have to query the alias table AND the account table?
People have said on this list that other examples have been posted, but I can't
find them. Can someone please help?
Re: Best way to protect backup-mx?
Em 07-08-2012 15:04, Stan Hoeppner escreveu: On 8/7/2012 11:45 AM, tobi wrote: Hi list, I'm currently doing some brainstorming on how to protect backup-mx servers from being directly contacted by clients. I found that postscreen can do this, but as far as I read only if the backup runs on the same machine. Another idea that came in my mind is that the backup-mx checks the postgrey status of the main-mx and rejects clients that have no record in master's postgrey. But this seems for me not very accurate. The only clear case would be if postgrey has no record for the client or does not answer at all because the entire server is down/having problems. But how to react on backup if the client has a record in masters postgrey? Or one could write a script for backup-mx that upon receiving mail tries to contact master and check if a testmail could be sent. If the testmail could be sent to master, then drop the connection from client on backup Somehow I have no idea what the "best" approach would be. Thanks a lot for any input/hints/tips The first thing you need to do is define for us what "protect backup-mx servers" means. What, exactly, do you want to protect them from? Seems to me he should also define "client"... MUA or another MTA? -- *Marcio Merlone*
Re: Best way to protect backup-mx?
Am 07.08.2012 20:04, schrieb Stan Hoeppner: > The first thing you need to do is define for us what "protect > backup-mx servers" means. What, exactly, do you want to protect > them from? > Sorry if my intention was only clear to myself ;-) I want to prevent clients from connecting my backup-mx as long as the main-mx is up and running. Like spammers sometimes try by connecting directly to a backup-mx instead trying main-mx first. tobi
Re: Best way to protect backup-mx?
Am 07.08.2012 22:03, schrieb tobi: > > Am 07.08.2012 20:04, schrieb Stan Hoeppner: >> The first thing you need to do is define for us what "protect >> backup-mx servers" means. What, exactly, do you want to protect >> them from? >> > > Sorry if my intention was only clear to myself ;-) > I want to prevent clients from connecting my backup-mx as long as the > main-mx is up and running. Like spammers sometimes try by connecting > directly to a backup-mx instead trying main-mx first. be carfeul with such things that you primary MX is up from the connection of your backup-MX means virtually nothing because this does not mean it is also from the route the delivering MTA takes i have a practical example where i would 100% say it is impossible if someone tells me the same: * Class C IP-Range * two IP-Addresses on the same server * one customer with a website on both ip-addresses * customer has one www-domain and another domain with ip-based SSL host our ISP had terrible routing problems from and to all sort of networks over some hours caused by a dying core-router my customer was sitting in his office on the same machine and was able to connect to 91.118.73.6 without any problem while he could not connect to 91.118.73.7 from the same machine while other customers could even not connect to 91.118.73.6 so we had * the same client * the same network hardware on the client side * the same ISP on the client side * the same ISp on oour side * the same route * the same network hardware on our side * even the same physical server on our side * after ISP has solved his troubles all went to normal operations so nobody can explain me how this was possible but this shows me that make the decision "my primary MX is up" is finally danherous and says virtually nothing if he is up for any incoming connect from somewhere else and if the primary MX is down from the delivering MTA he is absolutely right to try the backup-MX! signature.asc Description: OpenPGP digital signature
Re: Best way to protect backup-mx?
On 2012-08-07 tobi wrote: > Am 07.08.2012 20:04, schrieb Stan Hoeppner: >> The first thing you need to do is define for us what "protect >> backup-mx servers" means. What, exactly, do you want to protect >> them from? > > Sorry if my intention was only clear to myself ;-) > I want to prevent clients from connecting my backup-mx as long as the > main-mx is up and running. Like spammers sometimes try by connecting > directly to a backup-mx instead trying main-mx first. Why do you consider this a problem? Your backup MX should neither accept nor allow anything the primary MX wouldn't. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: error when using procmail to forward message
On Aug 7, 2012, at 1:18 PM, Ansgar Wiechers wrote: On 2012-08-07 Al Zick wrote: I setup procmail. I have a system wide config: LOGFILE=/var/log/procmail.log VERBOSE=on :0B: * (://[A-Za-z0-9.-]+\.ru) /dev/null :0: * ^Subject: (Rolex) /dev/null :0 * ^Subject: (anoncvs) ! m...@server1.com some...@server2.com I checked the log and it is putting spam in /dev/null, but there are errors in procmail.log when ever it tries to forward the emails: sendmail: warning: the Postfix sendmail command has set-uid root file permissions sendmail: warning: or the command is run from a set-uid root process sendmail: warning: the Postfix sendmail command must be installed without set-uid root file permissions These are warnings, not errors. You are correct! Is there a way to fix this? chmod u-s /usr/sbin/sendmail # ll /usr/sbin/sendmail lrwxr-xr-x 1 root wheel 21 May 12 20:33 /usr/sbin/sendmail -> /usr/ sbin/mailwrapper # ll /usr/sbin/mailwrapper -rwxr-sr-t 1 root wheel 7839 May 12 20:33 /usr/sbin/mailwrapper Do I want to change permissions on /usr/sbin/mailwrapper? Best Regards, Al
Re: error when using procmail to forward message
Al Zick: > >> I checked the log and it is putting spam in /dev/null, but there are > >> errors in procmail.log when ever it tries to forward the emails: > >> > >> sendmail: warning: the Postfix sendmail command has set-uid root file > >> permissions > >> sendmail: warning: or the command is run from a set-uid root process > >> sendmail: warning: the Postfix sendmail command must be installed > >> without set-uid root file permissions Your procmail program is set-uid root, and it invokes the Postfix sendmail command with set-uid root privileges. This is a security hole, especially when a non-root user can tell procmail what "sendmail" program it will run. Wietse
Re: mysql query suppressed?
email builder: >it says if you use "%d" in your query and the lookup key is not in >the form of "u...@domain.tld" (ie local part only), then the query >is "suppressed".? What is not clear about that? Wietse
Re: Failover gateway server
On 7/8/2012 3:48 μμ, Viktor Dukhovni wrote: This is difficult to automate reliably... Thank you Victor for all the valuable info. I see. A question: Could we use the format: /etc/postfix/transportmap example.com relay:[mail.example.com], relay:[mail2.example.com] to force relaying to *both* those servers (mail AND mail2) at the same time? According to the documentation, I don't see that's possible (it seems only one transport:nexthop definition is acceptable), but can we achieve this somehow (except using always_bcc on mail.example.com)? A second question: Is anyone aware of any (Linux) "smart" script automating (at least to some extent) reliably enough detection of a mail server failure (to avoid re-inventing the wheel), so that we can subsequently switch to a different transportmap? Thanks again, Nick
postfix thinks mysql managed email address is remote
I recently switched from using flat virtual files to using mysql to manage a virtual table. Email addresses that were set up prior to the switchover can be reached. But emails set up afterwards can't. I added verbose logging to the smtp processes by adding the -v parameter in master.cf With old email addresses set up prior to mysql, the resolve_clnt function seems to recognize that the domain is local, even though it doesn't initially see the email address in the virtual alias table (not sure why) With the new email addresses that are managed by mysql, resolve_clnt doesn't seem to be looking up the email in the virtual table. Instead, it comes back with the host IP address -- this is the relayhost value set in main.cf. Here are the maillog entries for the email set up prior to the mysql switch: [root@miltermatic log]# grep "sbr...@oldvirtualdomain.com" maillog Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: < mail-qc0-f177.google.com[209.85.216.177]: RCPT TO: Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: extract_addr: input: Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: smtpd_check_addr: addr=sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: send attr address = sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: input attribute value: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: rewrite_clnt: local: sbr...@oldvirtualdomain.com -> sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: send attr address = sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: input attribute value: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: resolve_clnt: `' -> `sbr...@oldvirtualdomain.com' -> transp=`error' host=`User unknown in virtual alias table' rcpt=`sbr...@oldvirtualdomain.com' flags= class=alias Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: ctable_locate: install entry key sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: extract_addr: in: , result: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: check_mail_access: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: ctable_locate: move existing entry key sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: check_access: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: reject_unauth_destination: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: permit_auth_destination: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: ctable_locate: leave existing entry key sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: reject_non_fqdn_address: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: reject_unknown_address: sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: ctable_locate: leave existing entry key sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: ctable_locate: leave existing entry key sbr...@oldvirtualdomain.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: maps_find: recipient_canonical_maps: sbr...@oldvirtualdomain.com: not found Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: mail_addr_find: sbr...@oldvirtualdomain.com -> (not found) Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: maps_find: canonical_maps: sbr...@oldvirtualdomain.com: not found Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: mail_addr_find: sbr...@oldvirtualdomain.com -> (not found) Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: maps_find: virtual_alias_maps: mysql:/etc/postfix/mysql-virtual.cf(0,lock|fold_fix): sbr...@oldvirtualdomain.com = scottwb...@yahoo.com Aug 7 17:52:13 miltermatic postfix/smtpd[15169]: mail_addr_find: sbr...@oldvirtualdomain.com -> scottwb...@yahoo.com Aug 7 17:52:14 miltermatic postfix/smtp[13404]: AEE0914A806A: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.6, delays=0.61/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BADEC14A8070) here are the maillog entries for the email set up after the mysql switch: [root@miltermatic log]# grep "sbr...@domainaftermysql.com" maillog Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: < mail-qc0-f170.google.com[209.85.216.170]: RCPT TO: Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: extract_addr: input: Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: smtpd_check_addr: addr=sbr...@domainaftermysql.com Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: send attr address = sbr...@domainaftermysql.com Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: input attribute value: sbr...@domainaftermysql.com Aug 7 17:50:03 miltermatic postfix/smtpd[15246]: rewrite_clnt: local: sbr...@domainaftermysql.com -> sbr...@domainaftermysql.com Au
Re: Failover gateway server
On Wed, Aug 08, 2012 at 12:58:41AM +0300, Nikolaos Milas wrote: > A question: Could we use the format: > > /etc/postfix/transportmap > example.com relay:[mail.example.com], relay:[mail2.example.com] No. As documented. > to force relaying to *both* those servers (mail AND mail2) at the > same time? According to the documentation, I don't see that's > possible (it seems only one transport:nexthop definition is > acceptable), but can we achieve this somehow (except using > always_bcc on mail.example.com)? You can use virtual_alias_maps to rewrite each user to two mailbox addresses and deliver to both, this is likely unwise. The two mailboxes are no longer identical, messages arrive out of order with slightly different content, deletion is difficult to synchronize, ... > A second question: Is anyone aware of any (Linux) "smart" script > automating (at least to some extent) reliably enough detection of a > mail server failure (to avoid re-inventing the wheel), so that we > can subsequently switch to a different transportmap? This decision is best not automated. If you want HA, design a resilient IMAP store, that supports LMTP delivery from multiple MTAs. The store will support replication of data in some fashion (block level with SANs, FS layer with NAS, mail store as a replicated database, ...) This is not a Postfix issue, you need to look at how this is done in Zimbra, Exchange, large-scale Cyrus IMAP deployments, ... The problem is not trivial, the architectures of the largest deployments (Gmail, ...) are not publically documented. -- Viktor.
Re: postfix thinks mysql managed email address is remote
On Tue, Aug 07, 2012 at 03:28:45PM -0700, Scott Brown wrote: > I recently switched from using flat virtual files to using mysql > to manage a virtual table. http://www.postfix.org/DEBUG_README.html#mail > Aug ?7 17:52:13 miltermatic postfix/smtpd[15169]: resolve_clnt: `' -> > `sbr...@oldvirtualdomain.com' -> transp=`error' host=`User unknown in virtual > alias table' rcpt=`sbr...@oldvirtualdomain.com' flags= class=alias This is a virtual alias domain. http://www.postfix.org/ADDRESS_CLASS_README.html > Aug ?7 17:50:03 miltermatic postfix/smtpd[15246]: resolve_clnt: `' -> > `sbr...@domainaftermysql.com' -> transp=`smtp' host=`67.22.105.2' > rcpt=`sbr...@domainaftermysql.com' flags= class=default This domain is not in any of the address classes, so it results to the default transport and the recipient is subject to "relay controls". > Aug ?7 17:50:04 miltermatic postfix/smtpd[15246]: NOQUEUE: reject: RCPT from > mail-qc0-f170.google.com[209.85.216.170]: 554 5.7.1 > : Relay access denied; > from= to= proto=ESMTP > helo= As expected if the client is not "trusted" to relay through your system. > I get "Relay access denied" if I try sending email to that domain > from gmail. ?If I try sending email to that domain with a manual > telnet smtp session to localhost port 25 on the machine postfix is > running on, it goes through fine: As expected, since "127.0.0.1" is a trusted client. -- Viktor.
orig_to missing in logs
Hello, today I noticed I don;t have orig_to in my log file even that the address is rewrited. I googled this problem with no luck. According to what Viktor wrote in this message http://www.mail-archive.com/postfix-users@postfix.org/msg08917.html orig_to should appear in case of virtual_alias_maps rewriting. Following this thread I have found an advice to do cleanup -v and watch logs. In fact address is modified by virtual_alias_maps but in logs I don't have orig_to (only the last address). How can I enable orig_to in logs? Is this because of delivering via dovecot service? Any help will be appreciated. Michal Below is logfile with cleanup -v (part with recipient address): Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A log_client_address=10.0.15.24 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A log_client_port=51933 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A log_message_origin=unknown[10.0.15.24] Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A log_helo_name=server2.abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A log_protocol_name=ESMTP Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A client_name=unknown Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A reverse_client_name=unknown Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A client_address=10.0.15.24 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A client_port=51933 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A helo_name=server2.abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A client_address_type=2 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope A dsn_orig_rcpt=rfc822;michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: initial envelope R michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr request = rewrite Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr rule = local Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr address = michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/rewrite socket: wanted attribute: flags Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: flags Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute value: 0 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/rewrite socket: wanted attribute: address Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: address Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute value: michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/rewrite socket: wanted attribute: (list terminator) Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: (end) Aug 8 00:13:43 mailserver postfix/cleanup[14571]: rewrite_clnt: local: michal.li...@abc.pl -> michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: been_here_check: michal.li...@abc.pl: 0 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr request = lookup Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr table = mysql:/etc/postfix/mysql_virtual_alias_maps.cf Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr flags = 16448 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr key = michal.li...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/proxymap socket: wanted attribute: status Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: status Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute value: 0 Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/proxymap socket: wanted attribute: value Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: value Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute value: mli...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: private/proxymap socket: wanted attribute: (list terminator) Aug 8 00:13:43 mailserver postfix/cleanup[14571]: input attribute name: (end) Aug 8 00:13:43 mailserver postfix/cleanup[14571]: dict_proxy_lookup: table=mysql:/etc/postfix/mysql_virtual_alias_maps.cf flags=lock|fold_fix key=michal.li...@abc.pl -> status=0 result=mli...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: maps_find: virtual_alias_maps: proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): michal.lipka@ abc.pl = mli...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: mail_addr_find: michal.li...@abc.pl -> mli...@abc.pl Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr request = rewrite Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr rule = local Aug 8 00:13:43 mailserver postfix/cleanup[14571]: send attr address = mli...@abc.pl Aug 8 00:13:43 mailserver post
Re: postfix thinks mysql managed email address is remote
On Tue, Aug 07, 2012 at 03:28:45PM -0700, Scott Brown wrote: > I recently switched from using flat virtual files to using mysql > to manage a virtual table. http://www.postfix.org/DATABASE_README.html#preparing is worth a read. > Email addresses that were set up prior to the switchover can be > reached. But emails set up afterwards can't. postmap -q new@address mysql:/path/to/your/query > I added verbose logging to the smtp processes by adding the -v > parameter in master.cf It looks like you added it to smtpd, not smtp. Probably was not necessary. > With old email addresses set up prior to mysql, the resolve_clnt > function seems to recognize that the domain is local, even though > it doesn't initially see the email address in the virtual alias > table (not sure why) Your post should have included "postconf -n" also. This would have been more useful than verbose logs. > With the new email addresses that are managed by mysql, > resolve_clnt doesn't seem to be looking up the email in the virtual > table. Instead, it comes back with the host IP address -- this is > the relayhost value set in main.cf. > > Here are the maillog entries for the email set up prior to the > mysql switch: > [root@miltermatic log]# grep "sbr...@oldvirtualdomain.com" maillog This grep string is going to miss some logging. [snip] > I get "Relay access denied" if I try sending email to that domain > from gmail. If I try sending email to that domain with a manual > telnet smtp session to localhost port 25 on the machine postfix is > running on, it goes through fine: Sounds like your domain lookup (virtual_mailbox_domains? Just guessing, because you did not show us) is failing, but your permit_mynetworks restriction accepts it locally. > Any help would be greatly appreciated! Repost including NON-verbose logs and postconf -n, plus the output of any relevant postmap -q lookups. Lose the grep: show an entire transaction for one each of working and non-working addresses. Lose the munging, because that will make mail routing issues hard to impossible to diagnose. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Failover gateway server
On 8/7/2012 5:32 PM, Viktor Dukhovni wrote: > On Wed, Aug 08, 2012 at 12:58:41AM +0300, Nikolaos Milas wrote: ... >> A second question: Is anyone aware of any (Linux) "smart" script >> automating (at least to some extent) reliably enough detection of a >> mail server failure (to avoid re-inventing the wheel), so that we >> can subsequently switch to a different transportmap? > > This decision is best not automated. If you want HA, design a > resilient IMAP store, that supports LMTP delivery from multiple > MTAs. The store will support replication of data in some fashion > (block level with SANs, FS layer with NAS, mail store as a replicated > database, ...) > > This is not a Postfix issue, you need to look at how this is done > in Zimbra, Exchange, large-scale Cyrus IMAP deployments, ... The > problem is not trivial, the architectures of the largest deployments > (Gmail, ...) are not publically documented. Yes, this is not a Postfix issue but a mail store issue. Nikolaos, what mail server are you using? Cyrus, Dovecot, other? As Viktor points out, building an HA mail server is not trivial. But we can probably point you to HA docs, and mailing lists, relevant to your mail server if we know what it is. -- Stan
Re: orig_to missing in logs
Michal Lipka: > Hello, > today I noticed I don;t have orig_to in my log file even that the address > is rewrited. Incorrect. Postfix logs orig_to only if the address is rewritten before it is delivered. For example Postfix does not log orig_to AFTER a content filter, when virtual alias expansion happened BEFORE the content filter. Wietse
Re: mysql query suppressed?
> email builder:
>> it says if you use "%d" in your query and the lookup key is not in
>> the form of "u...@domain.tld" (ie local part only), then the query
>> is "suppressed".?
>
> What is not clear about that?
1) the word "suppressed" is only slightly unclear. I just want to make sure I
understand the usage of this language ("not executed" in my words)
2) it's not intuitive to me that the query I have given to postifx is
conditionally executed. Generally, I would expect it to use the query in all
cases, letting me have control over what gets selected under any circumstance.
I guess what you're telling me is it's a known limitation of Postfix that I
cannot have a query that tests if %d is NULL. Unless there's a good reason to
do it that way, I'd encourage this to change in the next release
I have nicely asked if this wording is the same as "if you put %d in your query,
the query will not get executed when the lookup key only has the local
part." Is it that hard to confirm my question with "YES"??
Re: mysql query suppressed?
On Tue, Aug 07, 2012 at 09:17:48PM -0700, email builder wrote:
> > email builder:
> >> it says if you use "%d" in your query and the lookup key is not in
> >> the form of "u...@domain.tld" (ie local part only), then the query
> >> is "suppressed".?
> >
> > What is not clear about that?
>
>
> 1) the word "suppressed" is only slightly unclear. I just want to make sure I
> understand the usage of this language ("not executed" in my words)
As documented the query is suppressed, in other-words there is no
query. There is really no reasonable alternative interpretation.
It would be rather strange to run the query and then just throw
away any results.
The point of the query suppression is to make domain constraints
work, only keys that look like addresses have a meaningful domain
part. Otherwise, we can't distinguish between a bare domain and a
bare user name.
This feature is not going to change. Over and out.
--
Viktor.
Re: mysql query suppressed?
> This feature is not going to change. Over and out. I merely asked (politely I think) for confirmation that I understood the documentation correctly. Why do you have to use such unfriendly language in your responses?
