RE: {Spam?} Re: {Spam?} ehlo command failed
>> 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
No one can be allowed, telnet to this IP address (212.119.64.138) from
outside since this IP is restricted, top of this we have one more IP which
is 212.119.64.16 which is a virtual IP for 212.119.64.138 and
2121.119.64.139
Ejaz
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Reindl Harald
Sent: Sunday, June 12, 2011 10:36 PM
To: postfix-users@postfix.org
Subject: 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
--
This message has been scanned for viruses and
dangerous content by cyberia MailScanner, and is
believed to be clean.
Re: Issues with clamav-milter on Postfix
On 6/12/2011 8:46 PM, Janantha Marasinghe wrote: 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 Yes, the clamav milter works with postfix. Once you have postfix and clamav working separately, adding the milter to postfix is super easy. Things to check: - clamav-milter and postfix must use the same socket setting. - if you use a unix socket for clamav, postfix must have permission to read it. This usually means adding the postfix user to the clamav group. Sometimes it's easier to use a TCP socket so you don't have to worry about permissions. If you still have trouble, please see: http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
Re: Issues with clamav-milter on Postfix
Janantha Marasinghe: > 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 Welcome to the postfix mailing list. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix.
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
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
Re: {Spam?} Re: {Spam?} ehlo command failed
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 -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 pgpOK5HYesc7O.pgp Description: PGP signature
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
{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"
To: "Ejaz Mohammed"
Cc:
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?} 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?} 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: 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
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
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: 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 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
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: unverified_recipient_tempfail_action = permit
On 12 Jun 2011, at 11:23, Wiebe Cazemier wrote: > - Original Message - >> From: "Reindl Harald" >> 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
- Original Message - > From: "Reindl Harald" > 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
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
