Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: postfix-users@postfix.org Sent: Saturday, 11 June, 2011 6:23:59 PM Subject: Re: unverified_recipient_tempfail_action = permit Am 11.06.2011 16:55, schrieb Wiebe Cazemier: That's not what I meant. I meant that 99% of the time, the primary server will be up and recipient address verification will work to reject (spam) messages to unknown users. Those two scenario's you mentioned are when the primary is down or otherwise deferring. And those cases happen 1% of the time (figure meant to be illustrative). so you do not need any backup-MX because if your primary is not available the edferring happens on the sender this is teh way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. only if you have some database-driven configuration with a replications salve on the backup-mx it makes any sense because your configuration is independent, if you are using a spam-filtering appliance as example the backup-mx is the dead of your spam-filtering and if you are using greylsiting the backup-mx is also the dead of well working service becasue if the primary mx ansers with temporary problem the sending server will try your backup-mx and if both of them doing greylist you are playing something like ping-pong with the senders without any sync between the servers
Re: unverified_recipient_tempfail_action = permit
Am 12.06.2011 09:06, schrieb Wiebe Cazemier: so you do not need any backup-MX because if your primary is not available the deferring happens on the sender this is the way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. jokingly if you are longer than 3 times down with your primary MX you should consider outsourving you mailservices! really - in the last ten years our longest outage of the mailserver was 10 hours bcause a hardware-failure, so why does it bother me how long is the defer time out there and if our server si longer than 5 days down my smallest problem are a hand of mails bouncing back to the sender So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. IT DOES normally the backup-mx will get no messages as long as the primary is available so there are no valid/ivalid RCPT cached if your primary si down your backup-mx does know nothing and is a backscatter so cinfigure your mailservices properly or consider outsourcing them to anybody who can do this and makes a service level agreement where your mx is not down for some days signature.asc Description: OpenPGP digital signature
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: postfix-users@postfix.org Sent: Sunday, 12 June, 2011 10:04:02 AM Subject: Re: unverified_recipient_tempfail_action = permit Am 12.06.2011 09:06, schrieb Wiebe Cazemier: so you do not need any backup-MX because if your primary is not available the deferring happens on the sender this is the way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. jokingly if you are longer than 3 times down with your primary MX you should consider outsourving you mailservices! Well, I also have some private servers and if I'm on vacation, I have a hard time fixing broken hardware. At this time, I have no cloud platform or other redundant platform in place. Plus, people sending me mail will get a defer notice. I'd rather prevent that. really - in the last ten years our longest outage of the mailserver was 10 hours bcause a hardware-failure, so why does it bother me how long is the defer time out there and if our server si longer than 5 days down my smallest problem are a hand of mails bouncing back to the sender So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. IT DOES normally the backup-mx will get no messages as long as the primary is available so there are no valid/ivalid RCPT cached That is in a world where there is no spam. In a world where there is no spam, I don't need recipient address verification to reject mail on the backup to begin with. So when the primary is down, all is well. The only reason I do need recipient address verification is spam. And having the abused backup MX verify at the primary side, for me, is a good enough way to prevent backscatter. if your primary si down your backup-mx does know nothing and is a backscatter so cinfigure your mailservices properly or consider outsourcing them to anybody who can do this and makes a service level agreement where your mx is not down for some days I understand your point of view, but I think it should be possible to configure a MX server as backup for anyone who wants to use it, without maintaining extra address information, at the cost of creating backscatter when the primary is down (which can partly be avoided by installing good spam filtering).
Re: unverified_recipient_tempfail_action = permit
On 12 Jun 2011, at 11:23, Wiebe Cazemier wrote: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: postfix-users@postfix.org Sent: Sunday, 12 June, 2011 10:04:02 AM Subject: Re: unverified_recipient_tempfail_action = permit Am 12.06.2011 09:06, schrieb Wiebe Cazemier: so you do not need any backup-MX because if your primary is not available the deferring happens on the sender this is the way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. jokingly if you are longer than 3 times down with your primary MX you should consider outsourving you mailservices! Well, I also have some private servers and if I'm on vacation, I have a hard time fixing broken hardware. At this time, I have no cloud platform or other redundant platform in place. Plus, people sending me mail will get a defer notice. I'd rather prevent that. really - in the last ten years our longest outage of the mailserver was 10 hours bcause a hardware-failure, so why does it bother me how long is the defer time out there and if our server si longer than 5 days down my smallest problem are a hand of mails bouncing back to the sender So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. IT DOES normally the backup-mx will get no messages as long as the primary is available so there are no valid/ivalid RCPT cached That is in a world where there is no spam. In a world where there is no spam, I don't need recipient address verification to reject mail on the backup to begin with. So when the primary is down, all is well. The only reason I do need recipient address verification is spam. And having the abused backup MX verify at the primary side, for me, is a good enough way to prevent backscatter. if your primary si down your backup-mx does know nothing and is a backscatter so cinfigure your mailservices properly or consider outsourcing them to anybody who can do this and makes a service level agreement where your mx is not down for some days I understand your point of view, but I think it should be possible to configure a MX server as backup for anyone who wants to use it, without maintaining extra address information, at the cost of creating backscatter when the primary is down (which can partly be avoided by installing good spam filtering). Possible backscatter is no argument against this extra option. This has to be dealt with on the backup mx anyways. Outsourcing is not a fix either. We're talking about small-scale operations here. People who mostly run their servers for privacy reasons to avoid putting all their data in the iCloud. It already happened to me that I was on a ship for some days and found the primary mail server unresponsive for some reason. With a backup mx just blindly accepting everything in such a case, I just need to fix the primary and flush the backup mx to get all the mail delivered properly. I also kept a list of valid recipients on my backup mx for quite some time, but this is no elegant solution. I need to collect the list from various SLQ- and LDAP sources every few hours. Of course it works but when there is a new setup on the primary server, it's the first thing to be forgotten. Allowing unverified_recipient_tempfail_action=permit would help greatly with these smaller operations where: -emails should be accepted by _SOME_ server at all cost to prevent defer-messages. -the main server is not 100% reliable (because it's on a private ADSL-connection or so) -database replication for keeping a list of recipients isn't really worth it -but we still want some verification to prevent spam from piling up.
Re: unverified_recipient_tempfail_action = permit
Am 12.06.2011 11:50, schrieb Manuel Riel: I also kept a list of valid recipients on my backup mx for quite some time, but this is no elegant solution. I need to collect the list from various SLQ- and LDAP sources every few hours. man mysql replication man mysql ssl if your configuration is mysql-driven there is nothing to collect the slave on the backup-mx is in sync and if connection to the master is lost because the primary is down you have the latest configuration and even if you change something on the master after a longer outage the backup will be in sync after seeing the master again Of course it works but when there is a new setup on the primary server, it's the first thing to be forgotten then you make something wrong if you migrate to a new hardware rsync for all configurations is your friend and if you change elementary things on the primary you should always have the configs on the backup open in the same time or even test them first on the backup signature.asc Description: OpenPGP digital signature
Re: Transport to multiple destinations
Victor Duchovni: On Sat, Jun 11, 2011 at 07:48:42PM -0500, Dave Jones wrote: On Sat, Jun 11, 2011 at 6:29 PM, Wietse Venema wie...@porcupine.org wrote: Dave Jones: I am converting some sendmail boxes to postfix and can't find any information about multiple destinations (preferably primary / secondary). If it is not documented, then it is not implemented. With Postfix being as feature rich and superior in many ways, I can't believe a feature like this is not implemented. I though it might be something as simple as putting two lines in the transport or something . I guess I will try to script something so I can get off of sendmail. Customize your DNS. MTA localhost. zone file: example.com.localhost. IN MX 10 gw1.example.com. example.com.localhost. IN MX 20 gw2.example.com. Postfix transport table: example.com smtp:example.com.localhost Or /etc/hosts, if your libc implementation is not crippled: /etc/hosts: 1.2.3.4 gw.example.com 1.2.3.5 gw.example.com /etc/postfix/main.cf: smtp_host_lookup = native, dns That said, a Postfix built-in host-level aliasing feature would avoid the need to jump hoops like above. Wietse
postfix non-standard installation location quirks
Hi all, Trying to install postfix in a non-standard location (specifically /usr/local/ instead of /), I ran into two quirks, the second one more severe than the first one: Firstly, the naming of the config variable names the user is asked when saying make install is highly confusing: First, it is asking for the install_root, and then it is asking for destination directories and paths, providing something like /etc/postfix as default, which suggests that they are overriding the setting of install_root. When accepting the default or typing something else, it is later interpreted as relative to install_root EVEN IF it starts with a / . This is confusing. Maybe the description should be changed into Please enter XYZ *relative* to install_root, or the provided values should be interpreted as absolute paths if prepended with / and as relative paths (relative to install_root) if not. Secondly, the non-standard location is not reflected in main.cf . E.g. queue_directory still points to /var/spool/postfix/ . This is the value I typed in, and it was correctly (?) interpreted to be relative to /usr/local/, so make install created /usr/local/var/spool/postfix/ . Why is main.cf still pointing to /var/spool/postfix/ ? Is this the wrong target, or is the prefix /usr/local/ hardcoded in postfix somewhere after make install? After all, moving to autoconf would be a good idea because the generated Makefiles can handle non-standard installation locations very well, and it has become some sort of standard for C projects. I am using version 2.7.2 . Let me have it if this was fixed in the meantime. (Please, no questions as to why I want postfix to live in /usr/local/ instead of / .) - Winston
Re: postfix non-standard installation location quirks
On Mon, 2011-06-13 at 01:46:11 +1100, Winston Smith wrote: Trying to install postfix in a non-standard location (specifically /usr/local/ instead of /), I ran into two quirks, the second one more severe than the first one: Firstly, the naming of the config variable names the user is asked when saying make install is highly confusing: First, it is asking for the install_root, and then it is asking for destination directories and paths, providing something like /etc/postfix as default, which suggests that they are overriding the setting of install_root. When accepting the default or typing something else, it is later interpreted as relative to install_root EVEN IF it starts with a / . This is confusing. Maybe the description should be changed into Please enter XYZ *relative* to install_root, or the provided values should be interpreted as absolute paths if prepended with / and as relative paths (relative to install_root) if not. Secondly, the non-standard location is not reflected in main.cf . E.g. queue_directory still points to /var/spool/postfix/ . This is the value I typed in, and it was correctly (?) interpreted to be relative to /usr/local/, so make install created /usr/local/var/spool/postfix/ . Why is main.cf still pointing to /var/spool/postfix/ ? Is this the wrong target, or is the prefix /usr/local/ hardcoded in postfix somewhere after make install? Please see the postfix-install(1) script, specifically the section titled INSTALLATION PARAMETER DESCRIPTION. There, you are cautioned to specify install_root ONLY when creating pre‐built packages for distribution to other systems, and that the parameter setting is not recorded in main.cf. To install certain Postfix files under '/usr/local', pass that prefix to the installation parameter. For more information, carefully review the install script. After all, moving to autoconf would be a good idea because the generated Makefiles can handle non-standard installation locations very well, and it has become some sort of standard for C projects. There are no plans for moving to the beast that is autoconf; that, IMHO, is a good thing. -- Sahil Tandon sa...@freebsd.org
Re: postfix non-standard installation location quirks
Winston Smith: Hi all, Trying to install postfix in a non-standard location (specifically /usr/local/ instead of /), I ran into two quirks, the second one more severe than the first one: Please see the INSTALL document (or INSTALL.html) Wietse
{Spam?} ehlo command failed
I found several entries as following up on running postqueue -p, where 212.119.64.138 is my actual mailbox server (delivery temporarily suspended: conversation with fmbx01.cyberia.net.sa[212.119.64.138] timed out while performing the EHLO handshake Whereas threre is no problem up on telnet to 212.1119.64.38 : 25 [root@mailgate5 ~]# telnet 212.119.64.138 25 Trying 212.119.64.138... Connected to FMBX01.cyberia.net.sa (212.119.64.138). Escape character is '^]'. 220 fmbx01.cyberia.net.sa ESMTP CommuniGate Pro 5.3.12 is glad to see you! quit any help would be highly appreciated. ejaz -- This message has been scanned for viruses and dangerous content by cyberia MailScanner, and is believed to be clean.
Re: {Spam?} ehlo command failed
Ejaz Mohammed: [ Charset ISO-8859-1 unsupported, converting... ] I found several entries as following up on running postqueue -p, where 212.119.64.138 is my actual mailbox server (delivery temporarily suspended: conversation with fmbx01.cyberia.net.sa[212.119.64.138] timed out while performing the EHLO handshake Whereas threre is no problem up on telnet to 212.1119.64.38 : 25 [root@mailgate5 ~]# telnet 212.119.64.138 25 Trying 212.119.64.138... Connected to FMBX01.cyberia.net.sa (212.119.64.138). Escape character is '^]'. 220 fmbx01.cyberia.net.sa ESMTP CommuniGate Pro 5.3.12 is glad to see you! quit any help would be highly appreciated. You did not test the EHLO HANDSHAKE. Wietse
{Spam?} Re: {Spam?} ehlo command failed
You did not test the EHLO HANDSHAKE.
I ran this from the server which is complaining for a handshake, and below
is the result.
[root@mailgate5 ~]# telnet 212.119.64.138 25
Trying 212.119.64.138...
Connected to FMBX01.cyberia.net.sa (212.119.64.138).
Escape character is '^]'.
220 fmbx01.cyberia.net.sa ESMTP CommuniGate Pro 5.3.12 is glad to see you!
ehlo
250-fmbx01.cyberia.net.sa domain name should be qualified
250-DSN
250-SIZE
250-STARTTLS
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM
250-ETRN
250-TURN
250-ATRN
250-NO-SOLICITING
250-HELP
250-PIPELINING
250 EHLO
ejaz
- Original Message -
From: Wietse Venema wie...@porcupine.org
To: Ejaz Mohammed me...@cyberia.net.sa
Cc: postfix-users@postfix.org
Sent: Sunday, June 12, 2011 8:55 PM
Subject: Re: {Spam?} ehlo command failed
Ejaz Mohammed:
[ Charset ISO-8859-1 unsupported, converting... ]
I found several entries as following up on running postqueue -p, where
212.119.64.138 is my actual mailbox server
(delivery temporarily suspended: conversation with
fmbx01.cyberia.net.sa[212.119.64.138] timed out while performing the EHLO
handshake
Whereas threre is no problem up on telnet to 212.1119.64.38 : 25
[root@mailgate5 ~]# telnet 212.119.64.138 25
Trying 212.119.64.138...
Connected to FMBX01.cyberia.net.sa (212.119.64.138).
Escape character is '^]'.
220 fmbx01.cyberia.net.sa ESMTP CommuniGate Pro 5.3.12 is glad to see
you!
quit
any help would be highly appreciated.
You did not test the EHLO HANDSHAKE.
Wietse
--
This message has been scanned for viruses and
dangerous content by cyberia MailScanner, and is
believed to be clean.
Re: {Spam?} Re: {Spam?} ehlo command failed
Ejaz Mohammed: You did not test the EHLO HANDSHAKE. I ran this from the server which is complaining for a handshake, and below is the result. [root@mailgate5 ~]# telnet 212.119.64.138 25 Trying 212.119.64.138... Connected to FMBX01.cyberia.net.sa (212.119.64.138). Escape character is '^]'. 220 fmbx01.cyberia.net.sa ESMTP CommuniGate Pro 5.3.12 is glad to see you! ehlo 250-fmbx01.cyberia.net.sa domain name should be qualified 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 EHLO Next time, test the EHLO handshake when the error happens. Wietse
Re: {Spam?} Re: {Spam?} ehlo command failed
Am 12.06.2011 21:19, schrieb m...@smtp.fakessh.eu: Le dimanche 12 juin 2011 20:54, Wietse Venema a écrit : telnet 212.119.64.138 25 I just repeat the same test and get the other matches r13151 ~]# telnet 212.119.64.138 25 Trying 212.119.64.138... telnet: connect to address 212.119.64.138: Connection timed out telnet: Unable to connect to remote host: Connection timed out so what is your problem and why belongs this to the mailing-list? the other side has troubles, not your problem and that is why SMTP is designed as it is and defers signature.asc Description: OpenPGP digital signature
Issues with clamav-milter on Postfix
Hi All, I have installed clamav-milter on my postfix 2.7 which is running on ubuntu 10.04 server LTS. I have configured the config file where the socket is the clamav-milter.ctl but when postfix gets an e-mail it gives the warning the directory or file doesn't exist. has anyone got the clamav-milter working? a lot less documentation available on the net regarding it. thanks Jay
