Fax and SMS Forwarding
Hi community, i have set up a windows based GFI faxserver to send and receive fax and sms messages. the fax and sms connectors (faxmaker.com and smsmaker.com) for this faxserver are hostet on a other external exchange server. fax and sms messages are sended with smtp protocol. every time my suse mailserver (11.0) received a mail from a user account for the following domains xx...@faxmaker.com or xx...@smsmaker.com (x are fax- or celltel.-numbers) this mails must be redirected to the exchange server. How can i implement this function? redirect-table is only an information tool. kind regards oliver
Re: Queue monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2010 05:24 PM, Wietse Venema wrote: Mark Watts: I have a requirement to be able to monitor a postfix queue over time, and to determine whether any messages are delayed due to problems connecting to a remote servers. The mail system concerned is pretty simple; messages are generated locally and relayed to a remote server across a VPN. While I can monitor connectivity to port 25 on the remote server, that doesn't guarantee that it would accept a message for onward delivery; I need to be able to notice delivery issues and initiate a meatware interface. Once the message is accepted by the remote server, onward delivery is monitored by another system that I have no control over. I believe I am limited to monitoring the local mail queue to see if messages are being deferred, and reporting accordingly? The postqueue(1) command doesn't appear to generate output in a format particularly useful for scripts to parse, so is there another tool I can use or is there better way to approach this problem? QSHAPE (bundled with Postfix source) reports queue stats by age. http://www.postfix.org/QSHAPE_README.html Wietse This should do the trick - thanks. Mark. - -- Mark Watts BSc RHCE Senior Systems Engineer, Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzdyoACgkQBn4EFUVUIO2d/QCgnuYy/HhCZL4TN9UEMujUvQKO +8gAniS/R7Hd5rscYsAY5qbOjNMWV5xo =v0gR -END PGP SIGNATURE-
Re: Fax and SMS Forwarding
On 11/29/2010 03:15 PM, Schwalbe, Oliver wrote: Hi community, i have set up a windows based GFI faxserver to send and receive fax and sms messages. the fax and sms connectors (faxmaker.com and smsmaker.com) for this faxserver are hostet on a other external exchange server. fax and sms messages are sended with smtp protocol. every time my suse mailserver (11.0) received a mail from a user account for the following domains xx...@faxmaker.com mailto:xx...@faxmaker.com or xx...@smsmaker.com mailto:xx...@smsmaker.com (x are fax- or celltel.-numbers) this mails must be redirected to the exchange server. How can i implement this function? redirect-table is only an information tool. kind regards oliver Assuming you are using Postfix, you can use transport maps to do this . See : http://www.postfix.org/postconf.5.html#transport_maps http://www.postfix.org/transport.5.html
Re: Closing port 25
On Mon, Nov 29, 2010 at 08:53:43AM +0100, Mauro wrote: On 29 November 2010 01:56, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Sun, Nov 28, 2010 at 01:36:12PM -0700, ghe wrote: I run postfix and my mail clients use smtps so I was thinking I may as well close port 25. How can I do that? I'd use iptables or equivalent. I have my doubts about postfix itself because I think that'd be an RFC violation. So far... The above is nonsense. You don't have to accept traffic on port 25 of an MTA that is not an MX host (or whose IP is the A record) for a domain that needs to accept external email. How can you know if the inbound mail is coming from an MX host? Not from, but to. So if you have your MTA on an IP whose A record is not pointed by any MX record, and for sure, you don't want to accept mails for the rcpt domain either which is the A record, then it's fine not to even listen on tcp/25. Emailing is not compulsory, you can't be forced that you have an MTA in any way (otherwise even every webserver should accepts mails since they should be an A record at least). For sure, situation can be a bit different if you want to send mails with sender domains which is the same one with your MTA which is about to accept mails for that domain, otherwise eg no postmaster mails can be sent, and so on which is a problem. Also it can be important to be able to reply for the sender's mails :) But anyway, if you have only an MTA, which is about sending only, it's fine (till you handle the incoming mails for the domains you're sendign with somewhere else). I think most companies have different MTAs for accepting mails from the outside (called MX servers sometimes) and MTAs for sending mails to the outside and those won't accept any tcp/25 connection from outside, since that's the task of the MX servers not theirs.
Re: error with a single user
On 2010-11-29 Jon L Miller wrote: I'm getting a return error message when I try to send an email to a particular user: Reporting-MTA: dns; mail.domain.com.au X-Postfix-Queue-ID: B371FF687 X-Postfix-Sender: rfc822; jlmil...@mmtnetworks.com.au Arrival-Date: Mon, 29 Nov 2010 17:26:33 +0800 (WST) Final-Recipient: rfc822; kathy.lamp...@domain.com.au Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; mail for 192.168.5.201 loops back to myself Does anyone know how to rectify the error? Please post the output of postconf -n and relevant excerpts from your $virtual_mailbox_domains and $virtual_mailbox_maps. I have the user listed in the following db's linux-gw1:/etc/postfix # grep kathy * local_user_map:kathy.lamp...@domain.com.au kathy Binary file local_user_map.db matches virtual:kathy.lampard@@domain.com.aukathy Binary file virtual.db matches virtual_mailbox_recipients:kathy.lamp...@domain.com.au kathy Binary file virtual_mailbox_recipients.db matches The user should have either a local or a virtual mailbox. Not both at the same time. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: error with a single user
On Mon, Nov 29, 2010 at 01:09:30PM +0100, Ansgar Wiechers wrote: On 2010-11-29 Jon L Miller wrote: I'm getting a return error message when I try to send an email to a particular user: Do note, we strongly prefer to see logs here. Reporting-MTA: dns; mail.domain.com.au Also note, it's improper to use real Internet domain names as examples; we have example.TLD in every top-level domain for that. Domain Name:domain.com.au [ ... ] Registrant: FAIRFAX MEDIA LIMITED X-Postfix-Queue-ID: B371FF687 X-Postfix-Sender: rfc822; jlmil...@mmtnetworks.com.au Arrival-Date: Mon, 29 Nov 2010 17:26:33 +0800 (WST) Final-Recipient: rfc822; kathy.lamp...@domain.com.au Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; mail for 192.168.5.201 loops back to myself Loops back to myself means that the domain in question is not listed in any address class definition, so it is not recognized as one of this Postfix's own domains, but DNS or a transport(5) lookup said that it should be delivered to this Postfix. Does anyone know how to rectify the error? Please post the output of postconf -n and relevant excerpts from your $virtual_mailbox_domains and $virtual_mailbox_maps. I have the user listed in the following db's linux-gw1:/etc/postfix # grep kathy * local_user_map:kathy.lamp...@domain.com.au kathy Binary file local_user_map.db matches virtual:kathy.lampard@@domain.com.aukathy Binary file virtual.db matches virtual_mailbox_recipients:kathy.lamp...@domain.com.au kathy Binary file virtual_mailbox_recipients.db matches The user should have either a local or a virtual mailbox. Not both at the same time. Yes, and perhaps the OP is under the common misconception that a bare username with no @domain part means deliver to Unix user 'username'. This is not so. Best practice is to always use fully- qualified addresses as lookup results in your maps. Refer to: http://www.postfix.org/postconf.5.html#myorigin http://www.postfix.org/postconf.5.html#append_at_myorigin http://www.postfix.org/BASIC_CONFIGURATION_README.html Assuming (we can ONLY assume since there was no postconf -n provided with the post) that the file virtual is virtual_alias_maps, you should have something like this for local delivery instead: kathy.lampard@@domain.com.auka...@localhost with localhost, localhost.$mydomain included in your setting of $mydestination. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Address Rewriting for relayed emails
Dear all, Is it possible to configure postfix for the following scenario? Our ERP-System wants to send emails over a dedicated account to it's users. As it tries to send the email as the current user, using the users address, the e-mail gets rejected by our provider (who is running Exchange). As the providers security policy doesn't allow me to grant the Exchange Send as permission to the ERP-Account I want to do the following: Configure an internal postfix installation to accept these faked emails Forward them to the Exchange server replacing the faked senders address with the valid address of the account dedicated to the ERP-System. Is this possible? I guess I have to use the Address Rewriting capabilities in Postfix. But where to start? Kind regards and many thanks in advance Michael
Re: Address Rewriting for relayed emails
On 11/29/2010 9:24 AM, michael.h.gr...@googlemail.com wrote: Dear all, Is it possible to configure postfix for the following scenario? Our ERP-System wants to send emails over a dedicated account to it's users. As it tries to send the email as the current user, using the users address, the e-mail gets rejected by our provider (who is running Exchange). As the providers security policy doesn't allow me to grant the Exchange Send as permission to the ERP-Account I want to do the following: Configure an internal postfix installation to accept these faked emails Forward them to the Exchange server replacing the faked senders address with the valid address of the account dedicated to the ERP-System. Is this possible? I guess I have to use the Address Rewriting capabilities in Postfix. But where to start? Kind regards and many thanks in advance Michael Use the smtp_generic_maps feature to rewrite the bogus sender to a valid address. # main.cf smtp_generic_maps = hash:/etc/postfix/generic # /etc/postfix/generic bogus_u...@example.com u...@other.example.com Run postfix reload after editing main.cf. Run postmap generic after editing the map file. http://www.postfix.org/ADDRESS_REWRITING_README.html#generic You may also need: http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/SOHO_README.html http://www.postfix.org/STANDARD_CONFIGURATION_README.html http://www.postfix.org/ADDRESS_CLASS_README.html These and more can be found at http://www.postfix.org/documentation.html -- Noel Jones
Re: Address Rewriting for relayed emails
Am 29.11.2010 16:24, schrieb michael.h.gr...@googlemail.com: Dear all, Is it possible to configure postfix for the following scenario? Our ERP-System wants to send emails over a dedicated account to it's users. As it tries to send the email as the current user, using the users address, the e-mail gets rejected by our provider (who is running Exchange). As the providers security policy doesn't allow me to grant the Exchange Send as permission to the ERP-Account I want to do the following: Configure an internal postfix installation to accept these faked emails Forward them to the Exchange server replacing the faked senders address with the valid address of the account dedicated to the ERP-System. Is this possible? I guess I have to use the Address Rewriting capabilities in Postfix. But where to start? Kind regards and many thanks in advance Michael man generic u...@domain address Replace u...@domain by address. This form has the highest Precedence. HTH John
sender_dependent_default_transport_maps and recipient routing
Hi, I have a client with Postfix used as the main mail relay for a high volume e-commerce site. All mail to outbound destinations is relayed from sendmail processes to 2 main Postfix processes in the DMZ. Postfix relays everything to a separate Postini server outside. They've come to me with a requirement to do some mail filtering/routing at the Postfix layer. Postini can't do it, apparently. This is the first such request to manage mail routing in Postfix according to unique requirements. Until now everything is going through Postfix regardless of content, sender, recipient, etc. The new requirements requested are to: relay emails with Sender address f...@sub.domain.com and To address of *.bar.net to smtp.abc.bar.net All other mail should continue to go to the default relay (the Postini server). So, I looked into the manual and some list archives and found the sender_dependent_default_transport_maps option. I see how this could be used to alter the relay based on the Sender. OK. What I have not found and am for which I am requesting help, if anyone has a pointer or experience in this area, is the ability to combine the sender_dependent configuration with a recipient condition. Is there a straightforward way to configure this? Or do I need to script a custom filter? Or something else? Thank you for your time and any ideas or suggestions. Scott Stirling ATT, Boston
Re: sender_dependent_default_transport_maps and recipient routing
On Mon, Nov 29, 2010 at 11:40:13AM -0500, Stirling, Scott wrote: What I have not found and am for which I am requesting help, if anyone has a pointer or experience in this area, is the ability to combine the sender_dependent configuration with a recipient condition. Is there a straightforward way to configure this? Or do I need to script a custom filter? Or something else? Postfix has no recipient-dependent (required here since a message may have multiple recipients) mechanism of selecting the nexthop in a sender dependent way. This requires a second internal delivery hop. The first to separate out the recipients or senders that are candidates for bypassing Postini into a separate queue, and the second to route appropriate mail from that queue, either to Postini or not, based on the remaining criterion. -- Viktor.
RE: sender_dependent_default_transport_maps and recipient routing
What I have not found and am for which I am requesting help, if anyone has a pointer or experience in this area, is the ability to combine the sender_dependent configuration with a recipient condition. Is there a straightforward way to configure this? Or do I need to script a custom filter? Or ...? Postfix has no recipient-dependent (required here since a message may have multiple recipients) mechanism of selecting the nexthop in a sender dependent way. Thanks, Victor. OK, good to know. This requires a second internal delivery hop. The first to separate out the recipients or senders that are candidates for bypassing Postini into a separate queue, and the second to route appropriate mail from that queue, either to Postini or not, based on the remaining criterion. Sounds like one option would be to setup a separate Postfix instance and relay to it in sendmail based on Sender (using something like this sendmail mod, http://anfi.homeunix.net/sendmail/smarttab.html). The final step is to include/exclude that incoming mail for delivery to either Postini or not based on the recipient's address. Is recipient-based alternate routing possible once the Sender aspect is resolved with the additional internal hop? Any pointers? Thank you, Scott Stirling ATT, Boston
Re: Closing port 25
Le 29/11/2010 08:53, Mauro a écrit : On 29 November 2010 01:56, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Sun, Nov 28, 2010 at 01:36:12PM -0700, ghe wrote: I run postfix and my mail clients use smtps so I was thinking I may as well close port 25. How can I do that? I'd use iptables or equivalent. I have my doubts about postfix itself because I think that'd be an RFC violation. So far... The above is nonsense. You don't have to accept traffic on port 25 of an MTA that is not an MX host (or whose IP is the A record) for a domain that needs to accept external email. How can you know if the inbound mail is coming from an MX host? Your server is the MX host. inbound mail comes from anywhere (well, almost...). there's nothing to do about this. it's how it works! if you open a shop for people to come and buy things, then you'll need to have at least one open door, and people will come in via that door(s). so focus on blocking spam using the well known and proven techniques...
Re: sender_dependent_default_transport_maps and recipient routing
Le 29/11/2010 19:22, Stirling, Scott a écrit : What I have not found and am for which I am requesting help, if anyone has a pointer or experience in this area, is the ability to combine the sender_dependent configuration with a recipient condition. Is there a straightforward way to configure this? Or do I need to script a custom filter? Or ...? Postfix has no recipient-dependent (required here since a message may have multiple recipients) mechanism of selecting the nexthop in a sender dependent way. Thanks, Victor. OK, good to know. This requires a second internal delivery hop. The first to separate out the recipients or senders that are candidates for bypassing Postini into a separate queue, and the second to route appropriate mail from that queue, either to Postini or not, based on the remaining criterion. Sounds like one option would be to setup a separate Postfix instance and relay to it in sendmail based on Sender (using something like this sendmail mod, http://anfi.homeunix.net/sendmail/smarttab.html). The final step is to include/exclude that incoming mail for delivery to either Postini or not based on the recipient's address. Is recipient-based alternate routing possible once the Sender aspect is resolved with the additional internal hop? Any pointers? it's much easier than that! [two instances] otherwise, follow Viktor suggestion and use two instances (run postfix twice, with different configurations). the first instance sender_dependent_... to route mail from f...@sub.example.com to the second instance. the second instance has a transport entry to route .bar.net to smtp.abc.exaple.org, and a relay host to route the rest to postini postini. [single instance] if you want to play with a single instance, here is an ugly and UNTESTED idea: start 2 smtpd listeners: one on 25 (standard) and one one say 25001. A) on the standard smtpd, use check_sender_access hash:/etc/postfix/access_sender == access_sender f...@sub.example.comFILTER relay:[127.0.0.1]:25001 B) for the 25001 listener, setup a specific cleanup to rewrite the recipient with a specific virtual_alias_maps: /^(.*)@(.*\.bar\.net)$/ $...@deviate.$2 C) setup a transport entry deviate.bar.net smtp:[smtp.abc.example.org] D) create a generic entry to rewrite recipient address back: /^(.*)@deviate\.(.*\.bar\.net)$/$...@$2 yeah, a bit convoluted
Re: sender_dependent_default_transport_maps and recipient routing
On Mon, Nov 29, 2010 at 01:22:31PM -0500, Stirling, Scott wrote: This requires a second internal delivery hop. The first to separate out the recipients or senders that are candidates for bypassing Postini into a separate queue, and the second to route appropriate mail from that queue, either to Postini or not, based on the remaining criterion. Sounds like one option would be to setup a separate Postfix instance and relay to it in sendmail based on Sender (using something like this sendmail mod, http://anfi.homeunix.net/sendmail/smarttab.html). Yes. The final step is to include/exclude that incoming mail for delivery to either Postini or not based on the recipient's address. Is recipient-based alternate routing possible once the Sender aspect is resolved with the additional internal hop? Any pointers? Of course, that's what the Postfix transport table (akin to Sendmail's mailertable) does. http://www.postfix.org/transport.5.html No non-toy MTA fails to provide a per-domain transport override mechanism. -- Viktor.
Drop the rejects from a forwarded alias
Hi, I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. One way would be to drop all rejects. I think this will work because our server handles the $users and only forwards known. Or what would be the best practices way? Thanks, RCR
Re: Drop the rejects from a forwarded alias
Zitat von Randy Ramsdell rramsd...@activedg.com: Hi, I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. One way would be to drop all rejects. I think this will work because our server handles the $users and only forwards known. Or what would be the best practices way? Best practice is to not forward mail to destinations which don't accept it. If the detination has no feature of whitelist your server, disable forwarding to that destination. All other options lead to potential mail blackholes which are worse than spam. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Drop the rejects from a forwarded alias
Randy Ramsdell rramsd...@activedg.com: I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. If this alias is a mail distribution list, then it should be configured to override the envelope sender address, so that bounces aren't returned to the original sender, but to the maintainer of the mail distribution list. /etc/aliases: listname: owner-listname: u...@example.com See man 5 aliases and look for owner. Wietse
RE: sender_dependent_default_transport_maps and recipient routing
What I have not found and am for which I am requesting help, if anyone has a pointer or experience in this area, is the ability to combine the sender_dependent configuration with a recipient condition. Is there a straightforward way to configure this? Or do I need to script a custom filter? Or ...? Postfix has no recipient-dependent (required here since a message may have multiple recipients) mechanism of selecting the nexthop in a sender dependent way. Thanks, Victor. OK, good to know. This requires a second internal delivery hop. The first to separate out the recipients or senders that are candidates for bypassing Postini into a separate queue, and the second to route appropriate mail from that queue, either to Postini or not, based on the remaining criterion. Sounds like one option would be to setup a separate Postfix instance and relay to it in sendmail based on Sender (using something like this sendmail mod, http://anfi.homeunix.net/sendmail/smarttab.html). The final step is to include/exclude that incoming mail for delivery to either Postini or not based on the recipient's address. Is recipient-based alternate routing possible once the Sender aspect is resolved with the additional internal hop? Any pointers? it's much easier than that! [two instances] otherwise, follow Viktor suggestion and use two instances (run postfix twice, with different configurations). the first instance sender_dependent_... to route mail from f...@sub.example.com to the second instance. the second instance has a transport entry to route .bar.net to smtp.abc.exaple.org, and a relay host to route the rest to postini postini. [single instance] if you want to play with a single instance, here is an ugly and UNTESTED idea: start 2 smtpd listeners: one on 25 (standard) and one one say 25001. A) on the standard smtpd, use check_sender_access hash:/etc/postfix/access_sender == access_sender f...@sub.example.com FILTER relay:[127.0.0.1]:25001 B) for the 25001 listener, setup a specific cleanup to rewrite the recipient with a specific virtual_alias_maps: /^(.*)@(.*\.bar\.net)$/ $...@deviate.$2 C) setup a transport entry deviate.bar.net smtp:[smtp.abc.example.org] D) create a generic entry to rewrite recipient address back: /^(.*)@deviate\.(.*\.bar\.net)$/ $...@$2 yeah, a bit convoluted Thank you. With yours and Victor's input it sounds like I can do the first relay with the existing Postfix processes, configuring a sender_dependent relay to secondary instances of Postfix to handle candidates for custom routing from this Sender. Then in the secondary Postfix instances configure transport mappings with default transport to Postini but a domain transport entry to map: bar.net:smtp.abc.bar.net Anything off in my recap? Thank you, Scott Stirling ATT, Boston
Re: sender_dependent_default_transport_maps and recipient routing
On Mon, Nov 29, 2010 at 02:51:53PM -0500, Stirling, Scott wrote: Thank you. With yours and Victor's input it sounds like I can do the first relay with the existing Postfix processes, configuring a sender_dependent relay to secondary instances of Postfix to handle candidates for custom routing from this Sender. Then in the secondary Postfix instances configure transport mappings with default transport to Postini but a domain transport entry to map: bar.net:smtp.abc.bar.net The syntax of the transport map is not what you have above. Anything off in my recap? Otherwise OK. -- Viktor.
Re: Drop the rejects from a forwarded alias
lst_ho...@kwsoft.de wrote: Zitat von Randy Ramsdell rramsd...@activedg.com: Hi, I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. One way would be to drop all rejects. I think this will work because our server handles the $users and only forwards known. Or what would be the best practices way? Best practice is to not forward mail to destinations which don't accept it. If the detination has no feature of whitelist your server, disable forwarding to that destination. All other options lead to potential mail blackholes which are worse than spam. Regards Andreas I understand this. However, I cannot tell the President of our company that he can't use his exchange server and it is beyond my control to change the hosted exchange server configuration. I have to forward this mail no matter what I think should be done. So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter?
RE: sender_dependent_default_transport_maps and recipient routing
Thank you. With yours and Victor's input it sounds like I can do the first relay with the existing Postfix processes, configuring a sender_dependent relay to secondary instances of Postfix to handle candidates for custom routing from this Sender. Then in the secondary Postfix instances configure transport mappings with default transport to Postini but a domain transport entry to map: bar.net:smtp.abc.bar.net The syntax of the transport map is not what you have above. Bad interpretation of the man page. After checking examples, I think it would be like so: bar.net smtp:[smtp.abc.bar.net] Or does it need to be: bar.net relay:[smtp.abc.bar.net] What's the underlying difference between the effect of transport keywords relay and smtp? Is there technically a difference between the relay and smtp protocols? Thank you, Scott Stirling ATT, Boston
Re: Drop the rejects from a forwarded alias
On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote: So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter? If list expansion happens on your server, you can implement standard list management methods (an envelope sender address that is a list bounce-parser that uses VERP). If you are simply forwarding mail to an already expanded list, there is not much you can do. The list management problem is upstream, and needs to be handled there. -- Viktor.
Re: Drop the rejects from a forwarded alias
On 2010-11-29 Randy Ramsdell wrote: lst_ho...@kwsoft.de wrote: Zitat von Randy Ramsdell rramsd...@activedg.com: I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. One way would be to drop all rejects. I think this will work because our server handles the $users and only forwards known. Or what would be the best practices way? Best practice is to not forward mail to destinations which don't accept it. If the detination has no feature of whitelist your server, disable forwarding to that destination. All other options lead to potential mail blackholes which are worse than spam. I understand this. However, I cannot tell the President of our company that he can't use his exchange server and it is beyond my control to change the hosted exchange server configuration. I have to forward this mail no matter what I think should be done. Have you tried talking to the president of your company and/or the people who can change the hosted exchange server configuration? So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter? Then you cannot avoid being a backscatter source or a mail blackhole or both. Plain and simple. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: sender_dependent_default_transport_maps and recipient routing
On Mon, Nov 29, 2010 at 03:07:43PM -0500, Stirling, Scott wrote: Thank you. With yours and Victor's input it sounds like I can do the first relay with the existing Postfix processes, configuring a sender_dependent relay to secondary instances of Postfix to handle candidates for custom routing from this Sender. Then in the secondary Postfix instances configure transport mappings with default transport to Postini but a domain transport entry to map: bar.net:smtp.abc.bar.net The syntax of the transport map is not what you have above. Bad interpretation of the man page. After checking examples, I think it would be like so: bar.net smtp:[smtp.abc.bar.net] Or does it need to be: bar.net relay:[smtp.abc.bar.net] What's the underlying difference between the effect of transport keywords relay and smtp? Is there technically a difference between the relay and smtp protocols? These are not keywords, they are transport names. Transports are defined in master.cf. The smtp transport is for other people's domains, the relay transport is for your domains that are forwarded to other SMTP servers you manage. They are otherwise identical. http://www.postfix.org/ADDRESS_CLASS_README.html -- Viktor.
RE: sender_dependent_default_transport_maps and recipient routing
These are not keywords, they are transport names. Transports are defined in master.cf. Ahh, so the names are conventional, configurable. Flexible configurability is a theme with Postfix. The smtp transport is for other people's domains, the relay transport is for your domains that are forwarded to other SMTP servers you manage. They are otherwise identical. http://www.postfix.org/ADDRESS_CLASS_README.html I've read a lot of these doc pages once but they make more sense after talking through and getting some guidance what goes to what and why and how. Thank you very much, Scott Stirling
Re: Drop the rejects from a forwarded alias
Victor Duchovni wrote: On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote: So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter? If list expansion happens on your server, you can implement standard list management methods (an envelope sender address that is a list bounce-parser that uses VERP). If you are simply forwarding mail to an already expanded list, there is not much you can do. The list management problem is upstream, and needs to be handled there. We simply alias $user $u...@$othermailserver The $users we forward to are known by our mail server and no mail will forward otherwise. I cannot think of a scenario which rejected mail from $othermailserver would be anything other than UCE in this case. The fringe issues would be a borked config which reject because of misconfiguration on their end which would result is lost mail if we drop all rejects from $othermailserver. What scenarios could occur which would make dropping these rejects a bad idea?
Re: Drop the rejects from a forwarded alias
Zitat von Randy Ramsdell rramsd...@activedg.com: lst_ho...@kwsoft.de wrote: Zitat von Randy Ramsdell rramsd...@activedg.com: Hi, I am going to have to implement something that drops rejected mail from one of our aliases. The scenario is that we forward to a external server and cannot match its spam/UCE rules so our server backskatters mail. One way would be to drop all rejects. I think this will work because our server handles the $users and only forwards known. Or what would be the best practices way? Best practice is to not forward mail to destinations which don't accept it. If the detination has no feature of whitelist your server, disable forwarding to that destination. All other options lead to potential mail blackholes which are worse than spam. Regards Andreas I understand this. However, I cannot tell the President of our company that he can't use his exchange server and it is beyond my control to change the hosted exchange server configuration. I have to forward this mail no matter what I think should be done. So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter? Be prepared that your President will loose mail some time in the future. Try to tighten Spam rules as much as possible for accounts in question. a.) redirect bounces to some archive mailbox to prove that it was not your fault or b.) let bounces go its way and hope there are few enough so no one notices It's your choice but nothing of these can be called best practice. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Drop the rejects from a forwarded alias
Randy Ramsdell: We simply alias $user $u...@$othermailserver The $users we forward to are known by our mail server and no mail will forward otherwise. I cannot think of a scenario which rejected mail from $othermailserver would be anything other than UCE in this case. The fringe issues would be a borked config which reject because of misconfiguration on their end which would result is lost mail if we drop all rejects from $othermailserver. What scenarios could occur which would make dropping these rejects a bad idea? Spamfilters are imperfect and will have false rejects (either that, or they would pass all spam). This means you would be dropping legitimate mail into the bit bucket. A better approach is that the down-stream system not reject mail, instead provide a quarantine service. Wietse
Re: Drop the rejects from a forwarded alias
Zitat von Randy Ramsdell rramsd...@activedg.com: Victor Duchovni wrote: On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote: So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter? If list expansion happens on your server, you can implement standard list management methods (an envelope sender address that is a list bounce-parser that uses VERP). If you are simply forwarding mail to an already expanded list, there is not much you can do. The list management problem is upstream, and needs to be handled there. We simply alias $user $u...@$othermailserver The $users we forward to are known by our mail server and no mail will forward otherwise. I cannot think of a scenario which rejected mail from $othermailserver would be anything other than UCE in this case. The fringe issues would be a borked config which reject because of misconfiguration on their end which would result is lost mail if we drop all rejects from $othermailserver. What scenarios could occur which would make dropping these rejects a bad idea? UCE or not will dedecided by the *remote* Exchange and if it fails (reject non spam) you are responsible in the first place because the mail was *directed* to your server. Therefore be prepared to proof the rejects so you don't get blamed for others faults. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Drop the rejects from a forwarded alias
On 11/29/2010 12:28 PM, Randy Ramsdell wrote: We simply alias $user $u...@$othermailserver The $users we forward to are known by our mail server and no mail will forward otherwise. I cannot think of a scenario which rejected mail from $othermailserver would be anything other than UCE in this case. The fringe issues would be a borked config which reject because of misconfiguration on their end which would result is lost mail if we drop all rejects from $othermailserver. Hi Randy, Just wondering, why do you need two servers in the first place? Why not just set the MX to $othermailserver? Or, have $othermailserver forward to your server? Just trying to think of some alternatives... HTH, -will
multiple Postfix instances pre-2.6
http://www.postfix.org/MULTI_INSTANCE_README.html My client has Postfix 2.3.3. Must I update to 2.6+ to run multiple instances side-by-side? Could I manually create an instance by, e.g., creating an /etc/postfix-foo with main.cf and master.cf, and configure them to use different files and directories? Updating the postfix version might be a good idea for other reasons, but it would increase the scope of the issue a bit. Thank you, Scott Stirling ATT, Boston
Re: multiple Postfix instances pre-2.6
On Mon, Nov 29, 2010 at 05:39:40PM -0500, Stirling, Scott wrote: http://www.postfix.org/MULTI_INSTANCE_README.html My client has Postfix 2.3.3. Must I update to 2.6+ to run multiple instances side-by-side? No, but you won't have the postmulti(1) tooling at your disposal. Could I manually create an instance by, e.g., creating an /etc/postfix-foo with main.cf and master.cf, and configure them to use different files and directories? Yes. You'll need to manually tweak alternate_config_directories if you need postqueue and postdrop to function for non-default instances when invoked by non-root users. Also upgrades may not automatically find and upgrade all instances. Updating the postfix version might be a good idea for other reasons, but it would increase the scope of the issue a bit. If you want reasonably current TLS support and a Postfix release that is still maintained, upgrading is not a bad idea. -- Viktor.
Re: multiple Postfix instances pre-2.6
On Mon, Nov 29, 2010 at 05:39:40PM -0500, Stirling, Scott wrote: http://www.postfix.org/MULTI_INSTANCE_README.html My client has Postfix 2.3.3. Must I update to 2.6+ to run multiple instances side-by-side? Could I manually create an instance by, e.g., creating an /etc/postfix-foo with main.cf and master.cf, and configure them to use different files and directories? Updating the postfix version might be a good idea for other reasons, but it would increase the scope of the issue a bit. Back in those days, multiple instances were done, but they of course were much harder than they are now. You have to decide whether the pain of upgrading exceeds the pain of not upgrading. Personally I would recommend the former, using a SRPM from Simon Mudd: http://postfix.wl0.org/ ... it's not that painful. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: multiple Postfix instances pre-2.6
On 11/29/2010 02:39 PM, Stirling, Scott wrote: http://www.postfix.org/MULTI_INSTANCE_README.html My client has Postfix 2.3.3. Must I update to 2.6+ to run multiple instances side-by-side? Could I manually create an instance by, e.g., creating an /etc/postfix-foo with main.cf and master.cf, and configure them to use different files and directories? Updating the postfix version might be a good idea for other reasons, but it would increase the scope of the issue a bit. 2.3.3 is pretty stale - sounds like rhel5/centos. FWIW we use Simon Mudd's postfix 2.7.x rpms on our centos servers, with good results. Joe
Enforced TLS issue after Postfix upgrade
Hello, After upgrading from 2.5.x to 2.7.1 mail started queuing up to one particular domain (TLS security level: verify) with Server certificate not verified. Systems still on 2.5.x versions of Postfix transmit messages to that domain via enforced TLS just fine. Based on some testing with different version it seems that the change in behavior started with 2.6.0. The ST part of the CN contains an encoded string sequence of \xC3\xBC that represents the German u Umlaut. We have tons of domains setup for enforced TLS and this is the only one that is causing trouble. Warning messages in the log file are also tied to asn1 encoding and eventually CN appears with no value in the log. Which seems to suggest that the asn 1 encoded character is what causes the trouble. Some log information below. Regards, Martin Nov 29 22:14:23 server postfix/smtp[6740]: initializing the client-side TLS engine Nov 29 22:14:24 server postfix/smtp[6740]: setting up TLS connection to mx2.mlp-ag.com[195.170.185.78]:25 Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: TLS cipher list ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL Nov 29 22:14:24 server postfix/smtp[6740]: looking for session smtp:195.170.185.78:25:mx2.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL in smtp cache Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: certificate verification depth=3 verify=1 subject=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: certificate verification depth=2 verify=1 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: certificate verification depth=1 verify=1 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: certificate verification depth=0 verify=1 subject=/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=HRB 335755/C=DE/2.5.4.17=69168/ST=Baden-W\xC3\xBCrttemberg/L=Wiesloch/2.5.4.9=Alte Heerstrasse 40/O=MLP Finanzdienstleistungen Aktiengesellschaft Nov 29 22:14:24 server postfix/smtp[6740]: SSL_connect:SSLv3 read finished A Nov 29 22:14:24 server postfix/smtp[6740]: save session smtp:195.170.185.78:25:mx2.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL to smtp cache Nov 29 22:14:24 server postfix/smtp[6740]: warning: tls_text_name: mx2.mlp-ag.com[195.170.185.78]:25: error decoding peer subject CN of ASN.1 type=12 Nov 29 22:14:24 server postfix/smtp[6740]: warning: TLS library problem: 6740:error:0D07A0A0:asn1 encoding routines:ASN1_mbstring_copy:unknown format:a_mbstr.c:142: Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: Trusted subject_CN=, issuer_CN=VeriSign Class 3 Extended Validation SSL SGC CA Nov 29 22:14:24 server postfix/smtp[6740]: Trusted TLS connection established to mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Nov 29 22:14:24 server postfix/smtp[6740]: 193A714002: Server certificate not verified Nov 29 22:14:25 server postfix/smtp[6740]: setting up TLS connection to mx1.mlp-ag.com[195.170.185.77]:25 Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: TLS cipher list ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL Nov 29 22:14:25 server postfix/smtp[6740]: looking for session smtp:195.170.185.77:25:mx1.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL in smtp cache Nov 29 22:14:25 server postfix/smtp[6740]: SSL_connect:before/connect initialization Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: certificate verification depth=3 verify=1 subject=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: certificate verification depth=2 verify=1 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: certificate verification depth=1 verify=1 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: certificate verification depth=0 verify=1 subject=/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=HRB
Re: Enforced TLS issue after Postfix upgrade
On Tue, Nov 30, 2010 at 02:44:31AM +, Mueller, Martin (Messaging) wrote: After upgrading from 2.5.x to 2.7.1 mail started queuing up to one particular domain (TLS security level: verify) with Server certificate not verified. Postfix TLS support has not changed noticeably since 2.5. Systems still on 2.5.x versions of Postfix transmit messages to that domain via enforced TLS just fine. Based on some testing with different version it seems that the change in behavior started with 2.6.0. What's new in 2.6/2.7 is that finally and with good reason SSLv2 and its associated ciphers are disabled by default. http://www.postfix.org/postconf.5.html#smtp_tls_protocols It is also likely that are you are using a more recent version of OpenSSL, this can be more significant than any minor changes in Postfix. The ST part of the CN contains an encoded string sequence of \xC3\xBC that represents the German u Umlaut. The ST as you say, is not part of the CN it is part of the Distinguished Name or DN. Parts of the DN that are not the CN do not matter for peer verification. We have tons of domains setup for enforced TLS and this is the only one that is causing trouble. Warning messages in the log file are also tied to asn1 encoding and eventually CN appears with no value in the log. Which seems to suggest that the asn 1 encoded character is what causes the trouble. This is almost certainly a Red Herring. initializing the client-side TLS engine setting up TLS connection to mx2.mlp-ag.com[195.170.185.78]:25 mx2.mlp-ag.com[195.170.185.78]:25: TLS cipher list ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL Your TLS log level is a bit too verbose. Nov 29 22:14:24 server postfix/smtp[6740]: warning: TLS library problem: 6740:error:0D07A0A0:asn1 encoding routines:ASN1_mbstring_copy:unknown format:a_mbstr.c:142: Harmless noise unless you have peername verification turned on. What is the configured TLS security level? Nov 29 22:14:24 server postfix/smtp[6740]: Trusted TLS connection established to mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) The TLS handshake completes. Nov 29 22:14:24 server postfix/smtp[6740]: 193A714002: Server certificate not verified But you appear to have peername verification turned on. What is your tls security level for this destination? When testing with Postfix 2.7 compiled against OpenSSL 1.0.0a and also 1.0.0b with two patches from the upcoming 1.0.0c (due any day now) everything is normal. Your OpenSSL is perhaps less fortuitously selected than mine. smtp-finger: Connected to mx2.mlp-ag.com[195.170.185.78]:25 smtp-finger: 220 mx2.mlp-ag.com ESMTP smtp-finger: EHLO amnesiac.example.com smtp-finger: 250-mx2.mlp-ag.com smtp-finger: 250-8BITMIME smtp-finger: 250-SIZE 104857600 smtp-finger: 250 STARTTLS smtp-finger: STARTTLS smtp-finger: 220 Go ahead with TLS smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25 Matched CommonName mx2.mlp-ag.com smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25: Matched subject_CN=mx2.mlp-ag.com, issuer_CN=VeriSign Class 3 Extended Validation SSL SGC CA smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25 sha1 fingerprint 90:9A:37:16:7B:DB:5E:D4:0D:72:2F:E4:AA:38:4C:5C:9A:12:59:21 smtp-finger: Verified TLS connection established to mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/businessCategory=V1.0, Clause 5.(b)/serialNumber=HRB 335755/C=DE/postalCode=69168/ST=Baden-W\xC3\xBCrttemberg/L=Wiesloch/street=Alte Heerstrasse 40 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA Certificate: Data: Version: 3 (0x2) Serial Number: 5c:15:d9:5e:08:43:61:e7:6e:40:76:e5:a3:cd:7b:bc Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA Validity Not Before: Jul 1 00:00:00 2010 GMT Not After : Jul 1 23:59:59 2011 GMT Subject: 1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/businessCategory=V1.0, Clause 5.(b)/serialNumber=HRB 335755, C=DE/postalCode=69168, ST=Baden-W\xC3\xBCrttemberg, L=Wiesloch/street=Alte Heerstrasse 40, O=MLP Finanzdienstleistungen Aktiengesellschaft, OU=e-Services, CN=mx2.mlp-ag.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ba:9e:2d:b9:ea:23:90:d5:a1:28:71:d3:cf:a8: e5:4b:d0:da:2a:00:c4:21:40:8d:77:43:b8:df:73: 49:f9:d2:e8:ae:85:43:74:e1:aa:e2:53:8c:4b:54: 41:0f:b7:62:85:8b:3d:ad:e6:5c:ca:f7:f8:af:4d:
Re: Enforced TLS issue after Postfix upgrade
On Tue, Nov 30, 2010 at 12:56:08AM -0500, Victor Duchovni wrote: When testing with Postfix 2.7 compiled against OpenSSL 1.0.0a and also 1.0.0b with two patches from the upcoming 1.0.0c (due any day now) everything is normal. Your OpenSSL is perhaps less fortuitously selected than mine. I get the same (successfully decoded CN) results with 0.9.8p and Postfix 2.5. I don't have a build of Postfix 2.7 with OpenSSL 0.9.8. What combination are you using? It sounds like your OpenSSL has a problem parsing the CN encoding, this happens very far away from Postfix code, entirely within OpenSSL. -- Viktor.
Re: FrontBridge RFC 2920 write-up
On Nov 28, 2010, at 8:18 PM, Victor Duchovni wrote: My current theory is that the issue is FrontBridge specific, and is the result of some firewall or proxy software in front of Microsoft Exchange. An update; I gather there are eyes on the problem. Aloha, Michael. -- Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy...
