Re: Relay doubt
On Friday, March 13, 2009 at 22:09 CET, M. Rodrigo Monteiro fale...@rodrigomonteiro.net wrote: I have an Postfix as gateway for other domains (domain1, domain2, domain3). When domain1 send an e-mail to domain2, it goes to Postfix and then to domain2, and vice-versa. When domain2 send an e-mail to Internet, it goes to Postfix and then do the Internet. Don't think in terms of Postfix relays mail for domain X. Relay control is made on the basis of the client address (or authentication) and, unless you actively configure it otherwise, the sender domain is irrelevant. I want to know where to put the IPs of domain1 (2 and 3) to allow them to relay though Postfix. I put them in network_table mynetworks = hash:/etc/postfix/network_table /etc/postfix/network_table IP_DOMAIN_1 OK IP_DOMAIN_2 OK Yes, this is fine. smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, check_client_access regexp:/etc/postfix/white_list_ip, permit If this check_client_access restriction only returns OK it's useless since it only exempts clients from the permit restriction. smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_multi_recipient_bounce, reject_unauth_destination, check_sender_access regexp:/etc/postfix/white_list_from, check_recipient_access regexp:/etc/postfix/white_list_to, check_sender_access regexp:/etc/postfix/black_list_from, check_recipient_access regexp:/etc/postfix/black_list_to, check_client_access regexp:/etc/postfix/black_list_ip, check_client_access regexp:/etc/postfix/black_list_client_ip, check_policy_service inet:127.0.0.1:2501, permit smtpd_client_restrictions = regexp:/etc/postfix/ip-access, permit The problem is that the verifications in the check_sender_access and check_recipient_access is not in action, because the permit_mynetworks in the beginning smtpd_recipient_restrictions. Okay, so move those restrictions above permit_mynetworks. When placing check_sender_access restrictions above reject_unauth_destination in smtpd_recipient_restrictions, you must be very careful not to return OK in that table since that would make you an open relay. If the restriction must apply for clients in mynetworks, I suggest you move the restriction to smtpd_sender_restrictions instead. That way your server cannot turn into an open relay (for that reason, anyway). -- Magnus Bäck mag...@dsek.lth.se
Re: Multiple TLS certificates on multiple IPs
email builder a écrit : [snip] I do not support configurations with multiple myhostname/mydomain settings (or multiple settings for any domain-like parameter that determines how Postfix handles email). That's certainly fair. I can accept that I am stepping outside the use model with this and that maybe the sure bet would be to run multiple instances. I will, however, endeavor to test my idea and report back for others' edification if it works or not. you can use multiple postfix instances (run postfix multiple times, with different config_directory, queue_directory, data_directory...).
Re: relay_recipient_maps, aliases and LDAP
On Friday, March 13, 2009 at 18:02 CET, Marcio Merlone marcio.merl...@a1.ind.br wrote: Long time since I last deployed a postfix server, and things used to be much simpler. :) Now I have set a Ubuntu 8.04 server to work as an anti-spam/anti-virus gateway. Messages will be sent to amavis via transport_maps: domain.tld smtp:127.0.0.1:10024 Should be: domain.tld smtp:[127.0.0.1]:10024 and amavis will deliver the message to the final destination via smtp, instead to this gateway server. Is this ok or bad practice? I don't think it matters much, but it does have the consequence that if the downstream server is down, the messages will be run through amavisd-new again and again since it doesn't have a queue of its own. Anyway, this seems to be working and the problem is that I want to refuse mail for unknown users, so I made: alias_maps = hash:/etc/postfix/aliases relay_recipient_maps = ldap:/etc/postfix/ldapusers.cf $alias_maps Why list $alias_maps there? relay_recipient_maps is looked up with full addresses and @example.com wildcards. alias_maps is looked up with bare username. Besides, alias_maps doesn't even apply for relay domains, only local domains. relay_domains = $transport_maps This is not recommended. What would happen if you added another entry in your transport table? Let's say hotmail.com required special handling. Instant open relay! [...] This way, messages to t...@domain.tld are refused as unknown user. Any hint on how to accomplish this? Meanwhile I'll keep searching Google, but when searching for postfix, it comes with tons of results, will have to sort them all. To apply aliases to relay domains use virtual aliases. -- Magnus Bäck mag...@dsek.lth.se
Re: about relay server
tom lee a écrit : On Tue, Mar 10, 2009 at 4:14 PM, mouss mo...@ml.netoyen.net wrote: All mails sending from machine A via relaying machine B will arrive in machine C. I think I need to set up something in machine B so that there will be no mails bounce back to machine A. if you want machine B to send no bounces, check whether soft_bounce = yes is good for you Thanks. this option should work. For my case sending mail from A to C via relay machine B, machine A - relay machine B - Target machine C the bounced email will be sent back to machine A, is it sent from machine B or machine C? which bounce are you talking about? if machine C is down, machine B will queue the message for few days before generating a bounce. I mean should I set soft_bounce in both machine B and machine C, or just one of them? now, why do you want to block the bounces and delete the queued mail? DIscarding mail is not recommended.
Re: Mail filtering problem
Webmaster Bliss Corporation a écrit : Greetings, I am installing a Postfix Server, and I am having trouble setting up a spam filter with Spamassassin. I installed Postfix and it is working fine using virtual domains (I followed these instructions: http://www.howtoforge.com/linux_postfix_virtual_hosting). I also installed Spamassassin, which is working fine also (I tested it). The problem is that I cannot make the two work together. I followed the instructions found at http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, but the e-mails start looping inside the Postfix server. As soon as I disable the filter, I receive the e-mails duplicated several times. What am I doing wrong? Please tell me which information do you need to help me solve this problem. I am running postfix-2.5.5-1.fc9.i386 on a Linux 2.6.25.14-108.fc9.i686 with spamassassin-3.2.5-1.fc9.i386 instead of trying to use spamd directly, use amavisd-new. then you don't need to start spamd (amavisd-new calls SA functions directly). See http://www.ijs.si/software/amavisd/README.postfix.html
Re: relay_recipient_maps, aliases and LDAP
On Fri, Mar 13, 2009 at 2:02 PM, Marcio Merlone marcio.merl...@a1.ind.br wrote: Hello, Hi (again?), Long time since I last deployed a postfix server, and things used to be much simpler. :) Now I have set a Ubuntu 8.04 server to work as an anti-spam/anti-virus gateway. Messages will be sent to amavis via transport_maps: domain.tld smtp:127.0.0.1:10024 If you use transport_maps, domain.tld can be on mydestination/relay_domains/virtual_alias_domains, the delivery method will be replace by specified on transport_maps. and amavis will deliver the message to the final destination via smtp, instead to this gateway server. Is this ok or bad practice? Anyway, this seems to be working and the problem is that I want to refuse mail for unknown users, so I made: alias_maps = hash:/etc/postfix/aliases relay_recipient_maps = ldap:/etc/postfix/ldapusers.cf $alias_maps relay_domains = $transport_maps you are't using local LDA, so alias_maps no have effect. /etc/postfix/aliases: ti: foo, fee, bar ldapusers.cf points to my ldap server with my valid users, and works just fine also. The problem is with alias_maps, wich is not recognized as valid user, since: r...@jupiter:/etc/postfix# postmap -q ti hash:/etc/postfix/aliases foo, fee, bar r...@jupiter:/etc/postfix# ok, but: You need change your /etc/postfix/aliases to accept query for u...@domain.tdl to work on virtual_alias_maps. r...@jupiter:/etc/postfix# postmap -q t...@domain.tld hash:/etc/postfix/aliases r...@jupiter:/etc/postfix# This way, messages to t...@domain.tld are refused as unknown user. Any hint on how to accomplish this? Meanwhile I'll keep searching Google, but when searching for postfix, it comes with tons of results, will have to sort them all. Thanks in advance and best regards. -- Marcio Merlone I already explain to you about this in local postfix mailling list. -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net
Re: Multiple TLS certificates on multiple IPs
Wietse: I do not support configurations with multiple myhostname/mydomain settings (or multiple settings for any domain-like parameter that determines how Postfix handles email). email builder: That's certainly fair. I can accept that I am stepping outside the use model with this and that maybe the sure bet would be to run multiple instances. I will, however, endeavor to test my idea and report back for others' edification if it works or not. Please, DO NOT share details of unsupported configurations. Postfix internals are being updated on an ongoing basis and I don't need the support load from people who find that your stuff no longer works. Wietse
Re: order of multiple hash file entries
- Noel Jones njo...@megan.vbhcs.org schrieb: C. V. wrote: Hi, i've setup my mailsystem a while ago and query MySQL and LDAP vor address and domain mappings. Since both of them (database and directory) are more likely to be down of many reasons (network, connection overload etc.) i want to add a backup with hash files (hash:/some/file). To reduce the queries i need to know the order in which postfix uses the lists. After a lot of searching without success, i now ask you: Then just dump SQL and LDAP to a hash periodically and don't use those services directly in postfix. The order of the tables doesn't matter; if a MySQL or LDAP table is unavailable, postfix will tempfail all mail. Are you shure about this behavior? I can't believe that. Is ther any doc about it? cv
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) -- There is a tragic flaw in our precious Constitution, and I don t know what can be done to fix it. This is it: Only nut cases want to be president.
Re: non-alpha HELO
LuKreme wrote, at 03/14/2009 12:19 PM: On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... Actually, the specially designated syslog_name can be very useful, especially for troubleshooting migration. To see who's using the new port, use something like this: grep sasl /var/log/maillog | grep submit To see who's not: grep sasl /var/log/maillog | grep -v submit
Re: order of multiple hash file entries
On Saturday, March 14, 2009 at 17:08 CET, list-u...@backenhoernchen.de wrote: - mouss mo...@ml.netoyen.net schrieb: there's no backup. you have the choice between: - accepting temp failures if the backend is down - using a backedn that doesn't get down (hash, cdb, ...) ok, i am all for by the book but postfix has to have some kind of order. as in the other answer to my question, a behavior like described (if one of the map fails _caused by a network error_ and not the there is no such domain in this map) is hopefully not really implemented. but if so i'd rather just use local files. Lookup tables are tried in the order specified in the configuration, but if any of the tables returns a result OR FAILS, the traversal is terminated and that result is returned to the client. That is, given the configuration foo_bar_maps = ldap:/etc/postfix/foo.cf, hash:/etc/postfix/foo_backup the hash table WILL be consulted undr these circumstances: * The string being looked up isn't found in the LDAP table. The hash table WILL NOT be consulted under these circumstances: * The LDAP lookup fails. * The LDAP lookup returns OK, REJECT, an email address or whatever. Multiple maps support is not meant for fail-over of one map. it's like if they were concatenanted: if no match is found, move to the next map. Using them as fail-over would really be nice to do and i think shoult work. Okay, but why? If the failover table ISN'T up to date it may provide bad results if it's ever used. If the failover table IS up to date, why not use it all the time? [...] -- Magnus Bäck mag...@dsek.lth.se
Re: non-alpha HELO
On Mar 14, 2009, at 12:20 PM, LuKreme wrote: On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] If you really set syslog_name=postfix/submit, the above log entry would look more like: postfix/submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... How do you define 'useful' in this context? What were you expecting to see? I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) In my experience this feature is unreliable; once Mail.app succeeds in relaying via one of those ports (25, for example), I don't see that it *always* polls 465 and 587 if SASL fails on 25. But this is off-topic anyway. :) -- Sahil Tandon sa...@tandon.net
Re: order of multiple hash file entries
list-u...@backenhoernchen.de wrote: Using them as fail-over would really be nice to do and i think shoult work. postix does not concatenantes these maps because it trys them one by one - in which order? is there any documentation on that? There is no failover for table lookups. You can specify multiple failover servers for LDAP and *SQL lookups, but there is not and will never be an ignore errors flag. Either use robust network tables or use a local hash: copy. It makes no sense to use both. To answer your original question, tables are consulted in the order you specify, using the search order documented for the purpose of the table. If any lookup fails due to table unavailable, the mail will be tempfailed. If the network table is listed first and fails, all mail is tempfailed. If you list the hash: table first, why bother with the network table? -- Noel Jones
Re: READMEs, where can I find them?
KLaM Postmaster wrote: where can I find the postfix readme files, I have looked all over the postfix.com site, and while there is lots of documentation (man pages, how to, faqs, etc) but I cannot find the readme files except as embedded links. Is the a directory or something that contains just the readme files. My particular interest is in configuring the master.cf, I have read the master and the master.cf man pages, but I am looking for advise on how to configure services like smpts, submission etc. TIA JLA The README files are all the topic headings at http://www.postfix.org/documentation.html The web site contains the latest versions of these files. If you have an older postfix, you should consult the README files included with your distribution. You should be able to find them in postconf readme_directory If you have specific questions search the archives. If that doesn't help, feel free to ask. -- Noel Jones
Re: non-alpha HELO
LuKreme a écrit : On 13-Mar-2009, at 14:51, Jorey Bump wrote: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject Yeah, once I get TLS setup. I am running 2.5.6. I did change the submission port to o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o syslog_name=postfix/submit Just to see what would get logged, I went ahead and tried to use this. I knew it wouldn't work, but I was hoping for useful error messages. I got this: submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: lost connection after EHLO from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: connect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: timeout after UNKNOWN from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] submit/smtpd[32686]: disconnect from c-67-164-162-51.hsd1.co.comcast.net[67.164.162.51] Not that useful... test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT then check the response of EHLO. if it contains STARTTLS but not AUTH, then it means a client must use TLS before it can authenticate. if your MUA is configured to do AUTH but not TLS, this may be a problem. I wish more clients were like Mail.app in this respect, its default is to try 25, 465, and 587, so if all my users were using Mail.app, I could just switch things and it would 'do the right thing'. Is that true after initial configuration? It would be odd for a client to start probing alternate ports outside of a configuration wizard. Appears so. Its default setting is Use default ports (25, 465, 587) this would be only at setup time (when you add an account...). or maybe if connection to the configured port doesn't work anymore. otherwise, it would be a nuisance.
Re: order of multiple hash file entries
- Magnus Bäck mag...@dsek.lth.se schrieb: On Saturday, March 14, 2009 at 17:08 CET, list-u...@backenhoernchen.de wrote: - mouss mo...@ml.netoyen.net schrieb: Lookup tables are tried in the order specified in the configuration, but if any of the tables returns a result OR FAILS, the traversal is terminated and that result is returned to the client. That is, given the configuration foo_bar_maps = ldap:/etc/postfix/foo.cf, hash:/etc/postfix/foo_backup the hash table WILL be consulted undr these circumstances: * The string being looked up isn't found in the LDAP table. The hash table WILL NOT be consulted under these circumstances: * The LDAP lookup fails. * The LDAP lookup returns OK, REJECT, an email address or whatever. So, when i trun around you statemant foo_bar_maps = hash:/etc/postfix/foo_backup,ldap:/etc/postfix/foo.cf the hash should alway be asked first and when there ist no matching entry postfix will ask ldap, which might have newer entries. So i can dump ldap less often to the hash file. Using this I will certainly only reduce correct lookups. Since most lookups at least for mailboxes and aliases will fail the hash file because of SPAM attempts with random addresses, I probably do not reduce the queries that much. I just will only have the advantage of no 4xx denail when LDAP is down. Multiple maps support is not meant for fail-over of one map. it's like if they were concatenanted: if no match is found, move to the next map. Using them as fail-over would really be nice to do and i think shoult work. Okay, but why? If the failover table ISN'T up to date it may provide bad results if it's ever used. If the failover table IS up to date, why not use it all the time? You might be right at some point. I is - as always - a question of what you think is best for your setup. If you have millions of smtp requests a minute, using a hash file with refreshing it every 5 minutes is probably a good way. On the other hand a system which does not have as many as 100 requests a minute an LDAP or MySQL backend data does not change that much, at least domain and mailbox mappings dumped every hour or so would be fine. Aliases might be handled different so redirecting mail would take effect faster. Do you have/know about any documentation on which order mappings are tried. I believe you but to be certain I'd like to read it in some dev-doc or so. Thanks, cv [...] -- Magnus Bäck mag...@dsek.lth.se
backwards compatibility of OK in header_checks still needed?
Quote from header_checks (5): DUNNO Pretend that the input line did not match any pat- tern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO. I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. Isn't it better to use the same semantics as in restrictions? (Wasn't that what people ment when they used OK?) -- Henk van Oers
Re: backwards compatibility of OK in header_checks still needed?
Henk van Oers wrote: Quote from header_checks (5): DUNNO Pretend that the input line did not match any pat- tern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO. I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. It's basically the same as with check_recipient_access: on seeing particular recipient, you want to skip all further recipient checks. This is not how postfix works. It will look up subsequent header lines as usual. Isn't it better to use the same semantics as in restrictions? (Wasn't that what people ment when they used OK?) See above for recipient example -- in case there are multiple recipients of email. /mjt
Re: relay_based_on_MX
Can you explain how this feature could be enabled? One of our the services we offer our customers allows them to create as many domains as they like (on various DNS's), and we have a catchall mailbox that grabs any emails sent to those domains. Of course you are correct most of the content on there is spam (at times, over %90), but certain campaigns will have our customers sifting through those mountains of spam for accountability purposes, etc. On Mon, Feb 18, 2008 at 3:34 PM, Wietse Venema wie...@porcupine.org wrote: Joe Postfix: Does anyone know if postfix supports a feature equivalent to relay_based_on_MX in sendmail? Yes. However such features must not be used because they accept mail for non-existent recipients, and therefore 1) they fill the Postfix queue with non-deliverable MAILER-DAEMON messages, and 2) the MAILER-DAEMON messages that can be delivered will bother innocent people about mail that they did not send. Wietse
Re: backwards compatibility of OK in header_checks still needed?
Henk van Oers wrote: On Sat, 14 Mar 2009, Michael Tokarev wrote: Henk van Oers wrote: [] I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. [] Isn't it better to use the same semantics as in restrictions? (Wasn't that what people ment when they used OK?) See above for recipient example -- in case there are multiple recipients of email. Mmm, i do not see what you mean. All rules applies to one recipient independently of other recipients. If your rules returns REJECT for one recipient, this one particular recipient will be rejected. If it's DUNNO or OK or whatever instead, it, again, applies to this very recipient only. All other recipients, if any, will be evaluated independently, with their own REJECT/OK/DUNNO. The same is with header_checks, where each header line acts as individual recipient for smtpd_recipient_restrictions. You can't control how other header lines will be evaluated based on one particular line. If you want to evaluate whole set of headers at once, you'll have to use some other tools designed for that purpose, -- those are usually called content filters. I the case of multiple recipients there can be rejects for some, no tests for some others (OK), a few test for DUNNO recipients and all the checks for the rest. Right? Yes. For each recipient independently. /mjt
Re: relay_based_on_MX
Joe Postfix: Does anyone know if postfix supports a feature equivalent to relay_based_on_MX in sendmail? Wietse: Yes. However such features must not be used because they accept mail for non-existent recipients, and therefore 1) they fill the Postfix queue with non-deliverable MAILER-DAEMON messages, and 2) the MAILER-DAEMON messages that can be delivered will bother innocent people about mail that they did not send. Joe Postfix: Can you explain how this feature could be enabled? One of our the services we offer our customers allows them to create as many domains as they like (on various DNS's), and we have a catchall mailbox that grabs any emails sent to those domains. What happens when a spammer points an MX record at your server? Wietse Of course you are correct most of the content on there is spam (at times, over %90), but certain campaigns will have our customers sifting through those mountains of spam for accountability purposes, etc.
Re: backwards compatibility of OK in header_checks still needed?
Henk van Oers: Quote from header_checks (5): DUNNO Pretend that the input line did not match any pat- tern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO. I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. According to the above documentation, Postfix does not work that way. Whitelisting based on a single header line is unsafe. Doing a proper job requires an external content filter. Wietse
Re: backwards compatibility of OK in header_checks still needed?
On Sat, 14 Mar 2009, Michael Tokarev wrote: Henk van Oers wrote: On Sat, 14 Mar 2009, Michael Tokarev wrote: Henk van Oers wrote: [] I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. [] Isn't it better to use the same semantics as in restrictions? (Wasn't that what people ment when they used OK?) See above for recipient example -- in case there are multiple recipients of email. Mmm, i do not see what you mean. All rules applies to one recipient independently of other recipients. If your rules returns REJECT for one recipient, this one particular recipient will be rejected. If it's DUNNO or OK or whatever instead, it, again, applies to this very recipient only. All other recipients, if any, will be evaluated independently, with their own REJECT/OK/DUNNO. That is how i understand it, and the difference between OK and DUNNO is: OK= accept now, DUNNO= move to the next test in the list of restrictions. The same is with header_checks, where each header line acts as individual recipient for smtpd_recipient_restrictions. You can't control how other header lines will be evaluated based on one particular line. Aha, that is where i got confused. I was seeing the list of patterns as a list of restrictions. I should use a list of regexp tables and than there will be the same distinction between OK and DUNNO. Right?
Re: relay_based_on_MX
Wietse Venema: Joe Postfix: Does anyone know if postfix supports a feature equivalent to relay_based_on_MX in sendmail? Wietse: Yes. However such features must not be used because they accept mail for non-existent recipients, and therefore 1) they fill the Postfix queue with non-deliverable MAILER-DAEMON messages, and 2) the MAILER-DAEMON messages that can be delivered will bother innocent people about mail that they did not send. Joe Postfix: Can you explain how this feature could be enabled? One of our the services we offer our customers allows them to create as many domains as they like (on various DNS's), and we have a catchall mailbox that grabs any emails sent to those domains. What happens when a spammer points an MX record at your server? Postfix can be configured with permit_mx_backup to accept mail if any MX records points to the MTA, but unfortunately this feature is unsafe because it is so easy to abuse, and for this reason I would like to remove it in the future. Wietse Of course you are correct most of the content on there is spam (at times, over %90), but certain campaigns will have our customers sifting through those mountains of spam for accountability purposes, etc.
Re: Multiple TLS certificates on multiple IPs
email builder a écrit : [snip] I do not support configurations with multiple myhostname/mydomain settings (or multiple settings for any domain-like parameter that determines how Postfix handles email). That's certainly fair. I can accept that I am stepping outside the use model with this and that maybe the sure bet would be to run multiple instances. I will, however, endeavor to test my idea and report back for others' edification if it works or not. you can use multiple postfix instances (run postfix multiple times, with different config_directory, queue_directory, data_directory...). I know, but my thinking was that it's overkill because all I need is to serve a different TLS cert for each IP address, but no other changes are needed.
Re: Multiple TLS certificates on multiple IPs
I do not support configurations with multiple myhostname/mydomain settings (or multiple settings for any domain-like parameter that determines how Postfix handles email). email builder: That's certainly fair. I can accept that I am stepping outside the use model with this and that maybe the sure bet would be to run multiple instances. I will, however, endeavor to test my idea and report back for others' edification if it works or not. Please, DO NOT share details of unsupported configurations. Postfix internals are being updated on an ongoing basis and I don't need the support load from people who find that your stuff no longer works. Alright, I understand. However, I just realized that I actually might not need to change the domain. The -o overrides I need may only be the smtpd_tls_* settings. I was just concerned about name mismatches with the certificate, but whatever postfix thinks is the domain shouldn't affect the client's matching the domain name in the certificate itself to the domain it used to connect. Therefore, perhaps this proposal would NOT be outside the scope of what you find acceptable? 1.2.3.4:smtp inet n - n - - smtpd -o smtpd_tls_cert_file=/etc/postfix/domainA.crt -o smtpd_tls_key_file=/etc/postfix/domainA.key 4.3.2.1:smtp inet n - n - - smtpd -o smtpd_tls_cert_file=/etc/postfix/domainB.crt -o smtpd_tls_key_file=/etc/postfix/domainB.key
Re: reject outgoiong mail not from domain of host
Noel Jones a écrit : John G. Heim wrote: I want to make sure that any messages my system sends out always has a sender of someb...@math.wisc.edu. I am looking at configuring the smtpd_sender_restrictions directive. smtpd_sender_restrictions = hash:/etc/postfix/all_addresses_at_math_wisc_edu,reject Am I close? That would work if this is a MSA, ie. used for mail submission only and doesn't accept mail from the internet. And you should use check_sender_access hash:... rather than letting postfix use the default lookup key. For a general purpose mail server you could preface it with permit_auth_destination, something like: smtpd_sender_restrictions = permit_auth_destination check_sender_access hash:/etc/postfix/my_domains reject or simply: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/my_domains reject_unauth_destination As an added bonus you could add reject_unlisted_sender just before the reject to make sure the sender address exists. -- Noel Jones
Re: Multiple TLS certificates on multiple IPs
Wietse:
I do not support configurations with multiple myhostname/mydomain
settings (or multiple settings for any domain-like parameter that
determines how Postfix handles email).
email builder:
That's certainly fair. I can accept that I am stepping outside
the use model with this and that maybe the sure bet would be to
run multiple instances. I will, however, endeavor to test my idea
and report back for others' edification if it works or not.
Wietse:
Please, DO NOT share details of unsupported configurations.
Postfix internals are being updated on an ongoing basis and I don't
need the support load from people who find that your stuff no longer
works.
email builder:
Alright, I understand.
However, I just realized that I actually might not need to change
the domain. The -o overrides I need may only be the smtpd_tls_*
settings. I was just concerned about name mismatches with the
certificate, but whatever postfix thinks is the domain shouldn't
affect the client's matching the domain name in the certificate
itself to the domain it used to connect. Therefore, perhaps this
proposal would NOT be outside the scope of what you find acceptable?
1.2.3.4:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/etc/postfix/domainA.crt
-o smtpd_tls_key_file=/etc/postfix/domainA.key
4.3.2.1:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/etc/postfix/domainB.crt
-o smtpd_tls_key_file=/etc/postfix/domainB.key
I see no multiple settings for the same host/domain parameters here.
Postfix also needs to know that it is final destination for [1.2.3.4],
[4.3.2.1] and for all the corresponding domain names, otherwise mail
for those destinations will loop.
You need to list 1.2.3.4 and 4.3.2.1 in main.cf:proxy_interfaces
if those addresses don't already match main.cf:inet_interfaces,
and you need to list all the corresponding host/domain names in
mydestination, if those host/domain names aren't already listed in
virtual_{alias,mailbox}_maps.
Wietse
Re: backwards compatibility of OK in header_checks still needed?
Michael Tokarev wrote, On 3/14/09 4:13 PM: Henk van Oers wrote: [...] I the case of multiple recipients there can be rejects for some, no tests for some others (OK), a few test for DUNNO recipients and all the checks for the rest. Right? Yes. For each recipient independently. I don't believe this to be correct. With SMTP, accepting or rejecting a message based on its content is only possible for all recipients. There is no way to respond to the SMTP DATA command that expresses different handling for different recipients. The only place in the SMTP transaction that you can discriminate between recipients is the RCPT phase.
Re: Multiple TLS certificates on multiple IPs
Wietse:
I do not support configurations with multiple myhostname/mydomain
settings (or multiple settings for any domain-like parameter that
determines how Postfix handles email).
email builder:
That's certainly fair. I can accept that I am stepping outside
the use model with this and that maybe the sure bet would be to
run multiple instances. I will, however, endeavor to test my idea
and report back for others' edification if it works or not.
Wietse:
Please, DO NOT share details of unsupported configurations.
Postfix internals are being updated on an ongoing basis and I don't
need the support load from people who find that your stuff no longer
works.
email builder:
Alright, I understand.
However, I just realized that I actually might not need to change
the domain. The -o overrides I need may only be the smtpd_tls_*
settings. I was just concerned about name mismatches with the
certificate, but whatever postfix thinks is the domain shouldn't
affect the client's matching the domain name in the certificate
itself to the domain it used to connect. Therefore, perhaps this
proposal would NOT be outside the scope of what you find acceptable?
1.2.3.4:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/etc/postfix/domainA.crt
-o smtpd_tls_key_file=/etc/postfix/domainA.key
4.3.2.1:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/etc/postfix/domainB.crt
-o smtpd_tls_key_file=/etc/postfix/domainB.key
Wietse:
I see no multiple settings for the same host/domain parameters here.
Right, I was hoping this was more acceptable for official use.
Wietse:
Postfix also needs to know that it is final destination for [1.2.3.4],
[4.3.2.1] and for all the corresponding domain names, otherwise mail
for those destinations will loop.
You need to list 1.2.3.4 and 4.3.2.1 in main.cf:proxy_interfaces
if those addresses don't already match main.cf:inet_interfaces,
and you need to list all the corresponding host/domain names in
mydestination, if those host/domain names aren't already listed in
virtual_{alias,mailbox}_maps.
Right. I already have all those things set up, as it works fine listening on
the machine with the single TLS certificate for all interfaces and domains.
Seems like this will work, then.
Thanks VERY VERY much for your patience, support and the great wonderful
software and hard work you give to the world!
Re: non-alpha HELO
On 14-Mar-2009, at 13:02, mouss wrote: test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT Right, I do know that. Sorry if I wasn't clear, my only point was that what was actaully logged under submit was not useful and expressing disappointment that there wasn't something like TLS failed AUTH failed or Hey, dumbass, you forgot to create a valid cert. Something along those lines. Appears so. Its default setting is Use default ports (25, 465, 587) this would be only at setup time (when you add an account...). No, that is the setting, unless you change it, for the outgoing server (outgoing servers in Mail.app are separate from accounts), but it does appear to actaully default to the first one that succeeds, and doesn't like if if taht port (25) stops working. or maybe if connection to the configured port doesn't work anymore. otherwise, it would be a nuisance. Yes, it can be a nuisance... Oh, and someone asked what ISPs would ever block p587? I had a user who was unable to access the mail server from Darfur until I opened up a port above 1024 to SMTP. He was able to CHECK mail, but not send on either 25 or 587. I think I setup 2025 for him and everything worked fine, albeit at glacial speed. Then he discovered Squirrelmail and it's not been a problem since. It was almost like the Sudan had a single 128K DSL connection to the rest of the world -- Incredible! One of the worst performances of my career and they never doubted it for a second.
smtpd_tls_session_cache_database
In reading http://www.postfix.org/TLS_README.html and all the posts in the last 15 months with 'smtpd_tls_session_cache_database' in the subject (all 7 of them!), it is not clear to me how the smtpd_tls_session_cache_database file is created, or what exactly it contains. If the file is not present, postfix doesn't create it, but logs a fatal error. This is what I have so far: # TLS smtpd_tls_cert_file = /etc/postfix/server.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_loglevel = 2 # will drop to 0 or 1 after setup is complete smtpd_tls_security_level = may # smtpd_tls_session_cache_database = btree:$data_directory/ smtpd_sessions smtpd_tls_session_cache_timeout = 1800s # 30 minutes smtpd_starttls_timeout = 90s As for the pem file, the docs say that the certificate supplied must be usable as an SSL server cert and pass the -purpose test: $ openssl verify -purpose sslserver mail.covisp.net.pem error 18 at 0 depth lookup:self signed certificate OK Is that still considered a pass since it returns OK? (server.pem is a copy of mail.covisp.net.pem) Is there a way to test the /etc/postfix/server.pem file directly to see if it passes muster for postfix's use other than actually trying to connect? $ openssl s_client -starttls smtp -showcerts -connect 127.0.0.1:587 CONNECTED(0003) 69661:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ s23_clnt.c:478: And if the cert is self-signed does any part of: In order to verify a certificate, the CA certificate (in case of a certificate chain, all CA certificates) must be available. You should add these certificates to the server certificate, the server certificate first, then the issuing CA(s). still apply? If so, what is the CA cert for a self-signed cert? -- Charlie don't surf!
Re: smtpd_tls_session_cache_database
LuKreme: In reading http://www.postfix.org/TLS_README.html and all the posts in the last 15 months with 'smtpd_tls_session_cache_database' in the subject (all 7 of them!), it is not clear to me how the smtpd_tls_session_cache_database file is created, or what exactly it contains. If the file is not present, postfix doesn't create it, but logs a fatal error. What are: - the configuration - the corresponding error message
Re: backwards compatibility of OK in header_checks still needed?
On Sat, 14 Mar 2009, Wietse Venema wrote: Henk van Oers: Quote from header_checks (5): DUNNO Pretend that the input line did not match any pat- tern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO. I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. According to the above documentation, Postfix does not work that way. Whitelisting based on a single header line is unsafe. I know. spammers can insert/spoof whatever. Doing a proper job requires an external content filter. I want to reject as mutch as posible, so i have a header_checks file. To bypass the header check for trusted senders i tryed: if /^Return-Path:/ /trusted_sender/ OK endif As i now understand it, i have to put this header check in a separate file and the other header_check file will be ignored. Right? (and, yes i know, the sender can be spoofed, but the spammer will be rejected before the data fase)
Re: backwards compatibility of OK in header_checks still needed?
Henk van Oers wrote: On Sat, 14 Mar 2009, Wietse Venema wrote: Henk van Oers: Quote from header_checks (5): DUNNO Pretend that the input line did not match any pat- tern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO. I was trying to use action OK to jump out of header checks. That is: not only skip the next patterns, but also the next input lines. According to the above documentation, Postfix does not work that way. Whitelisting based on a single header line is unsafe. I know. spammers can insert/spoof whatever. Doing a proper job requires an external content filter. I want to reject as mutch as posible, so i have a header_checks file. To bypass the header check for trusted senders i tryed: if /^Return-Path:/ /trusted_sender/ OK endif As i now understand it, i have to put this header check in a separate file and the other header_check file will be ignored. Right? No, using multiple header_checks files changes nothing. There is no bypass method for header_checks. You can bypass further checks *for an individual line* by using DUNNO (or the deprecated form OK), but subsequent lines will still be checked. This is not configurable. The header_checks feature is a blunt tool intended for checks safe for all your mail. If you need finer control, there are other tools to use; content_filter, smtpd_proxy_filter, or milters. All mail is subject to header_checks, so don't use checks not appropriate for everybody. And all the above applies to body_checks too. This behavior is not likely to be changed anytime soon. It is possible to use separate header_checks and body_checks for the submission service in master.cf. See the archives for details. I think an example was posted about 10 days ago. History lesson: Back in the dark ages, postfix header_checks documentation listed OK as the action verb to bypass further checks *on that individual header*. The use of OK raised the false expectation that subsequent header lines would not be checked, and led to many questions on this list about header_checks OK not working when it was, in fact, working as documented and intended. The documentation was changed to DUNNO rather than OK in the hope to not raise false expectations, but the behavior of postfix has not changed. -- Noel Jones
Re: non-alpha HELO
LuKreme wrote: On 14-Mar-2009, at 13:02, mouss wrote: test the connection manually: $ telnet yourserv 587 ... EHLO yourclienthostname ... QUIT Right, I do know that. Sorry if I wasn't clear, my only point was that what was actaully logged under submit was not useful and expressing disappointment that there wasn't something like TLS failed AUTH failed or Hey, dumbass, you forgot to create a valid cert. Something along those lines. The logging is the same. You can increase logging with debug_peer_list, but it's not clear that will help... Setting smtpd_tls_log_level = 1 will show if the client established TLS. But you should really be testing with telnet and openssl s_client before you start testing with a MUA. Turn off TLS and test AUTH with a telnet session. Use openssl s_client just to test TLS connectivity - if you get the 220 greeting banner TLS is working correctly. The instructions at http://www.postfix.org/TLS_README.html#quick-start are about the simplest for setting up a self-signed certificate that will work with postfix. Follow them carefully. You can distribute the cacert.pem root public key so others can verify your cert, but that isn't usually necessary; they can just click the trust this server or whatever in their mail client after the initial untrusted certificate message. -- Noel Jones
