Best way to create a redundant server
Hello, Here is the situation, we have a primary mail server located in the data center of an African Operator. Unfortunately the internet link is not steady at all and It tends to fail every week for couple of hours and sometimes even for days. For strategical reasons this server can not be located in another country or in another place. I have setup another server (backup MX), but this does not allow our users to access their mail while the server is down or to post mail during the failed time. It only allows not to loose mail. --- I wanted to know what you suggest me as a solution to create a usable "emergency" server that could be used while the main server is down. Thanks for you help. Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
Mixing Unix accounts (PAM) and database
Hello, I am trying to figure out if it is possible to mix both "shared domains with UNIX system accounts" && "virtual MAILBOX with separate domains, non-UNIX accounts" at the same time. The reason for this is quite simple : I have a mail server with Postfix installed since quite a long time and Local Unix users. I wish to migrate this server but I am not necessarily wishing to call all my customers to guide them to reconfigure their accounts… So the idea was to mix both… I am using dovecot as authentication scheme for SASL. A MySQL database is deployed with some new accounts in It. What will be your roadmap for this migration ? Can I mix both type of accounts / config (local with Unix type && virtual) ? Thanks for your reply Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
Whitelisting secondary MX for spf check
Hello, I am using two postfix server and quite often some misconfigured mail server are sending mail to the backup MX instead of the primary. Both server have postfix implemented using the 'classic' conf: in main.cf smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access hash:/usr/local/etc/postfix/access reject_unauth_destination, reject_invalid_hostname, reject_unknown_sender_domain, # SPF implementation check_policy_service unix:private/policy # Greylisting implementation check_policy_service inet:127.0.0.1:10023 and in master.cf : # SPF policy implementation /usr/ports/mail/postfix-policyd-spf policy unix - n n - - spawn user=nobody argv=/usr/local/sbin/postfix-policyd-spf The problem is that I sometimes have (quite often in fact) rejected mail because they are using spf and the mail is transfered from my backup MX to my master server and my server is considering that second server as the issuer. Is there any option that I can activate on master.cf or main.cf to avoid that… my initial reading and googling have not been very successful. Thanks. Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
Architecture design for frontend postfix server
Hello folks, I am trying to figure out what is the best solution in order to filter incoming e-mail on a front-end relay server quite heavily loaded (100.000 messages / day). We are using LDAP querry in amavisd-new in order to check if the e-mail account exists in our LDAP DB. Internet <--> Relay [Postfix + Amavisd-new] <--> Internal postfix | | | | [LDAP database]-- Since update of our amavisd-new server to version 2.7.0 we are having problem with the LDAP lookup. I was wondering if It was not better to do this lookup before delivering the e-mail to the amavisd process ? If the answer is positive, should I use the "local_recipient_maps" parameter or is there another more efficient method to be used ? E-mail are flowing both from the Internet to the Internal server and from Internal server to the Internet. Thanks for your support. –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Architecture design for frontend postfix server
Le 9 nov. 2011 à 11:43, Patrick Ben Koetter a écrit : > * bsd : >> I am trying to figure out what is the best solution in order to filter >> incoming e-mail on a front-end relay server quite heavily loaded (100.000 >> messages / day). > > Even if you assume that all those messages will be sent within 8 hours > (business time) it will boil down to ~ 3.5 msg/sec. Server hardware can do > that easily. > > >> We are using LDAP querry in amavisd-new in order to check if the e-mail >> account exists in our LDAP DB. > > Bad idea. That was also my feeling about this… > >> Internet <--> Relay [Postfix + Amavisd-new] <--> Internal postfix >> | | >> | | >> [LDAP database]-- >> >> >> >> Since update of our amavisd-new server to version 2.7.0 we are having >> problem with the LDAP lookup. >> >> I was wondering if It was not better to do this lookup before delivering the >> e-mail to the amavisd process ? > > Good idea. Reject any message that can't be delivered immediately. That's > cheap. It takes place in the SMTP session before the payload has been sent and > before a content filter, such as amavis, does ressource intensive filtering. Shall I do that using the "Postfix Before-Queue Content Filter", if so is It feasible or do you advise me to do that in the normal SMTP server using the classic "virtual_alias_maps" That would give smthg like : Unfiltered -> before Q -> smtpd -> cleanup -> postfix Q -> smtpd (filtered) ^| |v smtpd 10026 smtp ^| |v Amavisd filter 10025 > >> If the answer is positive, should I use the "local_recipient_maps" parameter >> or is there another more efficient method to be used ? > > Depends on the namespace the recpient domain is in. recipient would be in smthg like user@mydomain(s) where domains = less than 10 domains. > > p@rick > > -- > All technical questions asked privately will be automatically answered on the > list and archived for public access unless privacy is explicitely required and > justified. > > saslfinger (debugging SMTP AUTH): > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Architecture design for frontend postfix server
Le 9 nov. 2011 à 14:24, Patrick Ben Koetter a écrit : > * bsd : >>> Good idea. Reject any message that can't be delivered immediately. That's >>> cheap. It takes place in the SMTP session before the payload has been sent >>> and >>> before a content filter, such as amavis, does ressource intensive filtering. >> >> Shall I do that using the "Postfix Before-Queue Content Filter", if so is It >> feasible or do you advise me to do that in the normal SMTP server using the >> classic "virtual_alias_maps" > > > Before or After Queue Filtering depends on legal requirements and how your > server can take the load. > > In Germany, for example, you have to reject in session or you will get intro > trouble if you decide at a later stage to accept, but discard the message > later, because to the law this means you suppress delivery - which is a crime > in Germany. > > And, if your server is so busy that it can't process message filtering while > the client waits for the server to accept the message, you should consider > After Queue Filtering. > > As for your question regarding *_maps. Is your server a border filter (vulgo > SMTP Gateway) which accepts messages and forwards them to other servers or is > it a final destination where clients come to pick up messages? It is a SMTP Gateway delivering to another internal server. In fact there are two Gateways server with equal MX weight. > > p@rick > > > -- > All technical questions asked privately will be automatically answered on the > list and archived for public access unless privacy is explicitely required and > justified. > > saslfinger (debugging SMTP AUTH): > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Problem with SMTPs SSL_accept error | lost connection after CONNECT
Hi, I am trying to debug a problem that we have with one of my client. The symptoms are a very high difficulty to connect to our server : Jan 18 18:15:55 newmail postfix/smtpd[83432]: connect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:15:55 newmail postfix/smtpd[83782]: connect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:15:55 newmail postfix/smtpd[83783]: connect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:15:55 newmail postfix/smtpd[83785]: connect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:15:55 newmail postfix/smtpd[83784]: connect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83784]: SSL_accept error from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 Jan 18 18:20:54 newmail postfix/smtpd[83784]: lost connection after CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83784]: disconnect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83785]: SSL_accept error from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 Jan 18 18:20:54 newmail postfix/smtpd[83785]: lost connection after CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83785]: disconnect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83782]: SSL_accept error from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 Jan 18 18:20:54 newmail postfix/smtpd[83782]: lost connection after CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83782]: disconnect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83783]: SSL_accept error from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 Jan 18 18:20:54 newmail postfix/smtpd[83783]: lost connection after CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83783]: disconnect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83432]: SSL_accept error from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 Jan 18 18:20:54 newmail postfix/smtpd[83432]: lost connection after CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] Jan 18 18:20:54 newmail postfix/smtpd[83432]: disconnect from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] The client which is using Apple Mail seems to have persistent problem with his e-mail. I wanted to know what are the symptoms of "SSL_accept error" and "lost connection after CONNECT" ?? Should I inspect my configuration (which seems to work very well beside this) or is it coming from the net or the client side ? What would you advise me to further debug this ? Thx. –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT
Le 18 janv. 2012 à 23:44, Noel Jones a écrit : > On 1/18/2012 4:34 PM, bsd wrote: >> Hi, >> >> I am trying to debug a problem that we have with one of my client. >> The symptoms are a very high difficulty to connect to our server : >> >> >> Jan 18 18:15:55 newmail postfix/smtpd[83432]: connect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:15:55 newmail postfix/smtpd[83782]: connect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:15:55 newmail postfix/smtpd[83783]: connect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:15:55 newmail postfix/smtpd[83785]: connect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:15:55 newmail postfix/smtpd[83784]: connect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83784]: SSL_accept error from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >> Jan 18 18:20:54 newmail postfix/smtpd[83784]: lost connection after CONNECT >> from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83784]: disconnect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83785]: SSL_accept error from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >> Jan 18 18:20:54 newmail postfix/smtpd[83785]: lost connection after CONNECT >> from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83785]: disconnect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83782]: SSL_accept error from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >> Jan 18 18:20:54 newmail postfix/smtpd[83782]: lost connection after CONNECT >> from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83782]: disconnect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83783]: SSL_accept error from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >> Jan 18 18:20:54 newmail postfix/smtpd[83783]: lost connection after CONNECT >> from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83783]: disconnect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83432]: SSL_accept error from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >> Jan 18 18:20:54 newmail postfix/smtpd[83432]: lost connection after CONNECT >> from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> Jan 18 18:20:54 newmail postfix/smtpd[83432]: disconnect from >> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >> >> >> The client which is using Apple Mail seems to have persistent problem with >> his e-mail. >> >> I wanted to know what are the symptoms of "SSL_accept error" and "lost >> connection after CONNECT" ?? >> >> Should I inspect my configuration (which seems to work very well beside >> this) or is it coming from the net or the client side ? >> What would you advise me to further debug this ? > > 'lost connection after CONNECT' means the far end connected and then > disconnected. Maybe the client has a buggy TLS. You can > selectively turn off TLS for that client by setting: > > # main.cf > smtpd_discard_ehlo_keyword_address_maps = > cidr:/etc/postfix/smtpd_keyword_maps > > # smtpd_keyword_maps > 99.98.44.85 STARTTLS > > http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps > > If I turn off TLS for that specific client and he needs to authenticate through TLS (SMTPs) I am not sure this will solve my problem ? Or am I missing something ? > > -- Noel Jones –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT
Le 19 janv. 2012 à 00:12, Noel Jones a écrit : > On 1/18/2012 4:53 PM, bsd wrote: >> >> Le 18 janv. 2012 à 23:44, Noel Jones a écrit : >> >>> On 1/18/2012 4:34 PM, bsd wrote: >>>> Hi, >>>> >>>> I am trying to debug a problem that we have with one of my client. >>>> The symptoms are a very high difficulty to connect to our server : >>>> >>>> >>>> Jan 18 18:15:55 newmail postfix/smtpd[83432]: connect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:15:55 newmail postfix/smtpd[83782]: connect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:15:55 newmail postfix/smtpd[83783]: connect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:15:55 newmail postfix/smtpd[83785]: connect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:15:55 newmail postfix/smtpd[83784]: connect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83784]: SSL_accept error from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >>>> Jan 18 18:20:54 newmail postfix/smtpd[83784]: lost connection after >>>> CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83784]: disconnect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83785]: SSL_accept error from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >>>> Jan 18 18:20:54 newmail postfix/smtpd[83785]: lost connection after >>>> CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83785]: disconnect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83782]: SSL_accept error from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >>>> Jan 18 18:20:54 newmail postfix/smtpd[83782]: lost connection after >>>> CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83782]: disconnect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83783]: SSL_accept error from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >>>> Jan 18 18:20:54 newmail postfix/smtpd[83783]: lost connection after >>>> CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83783]: disconnect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83432]: SSL_accept error from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85]: 0 >>>> Jan 18 18:20:54 newmail postfix/smtpd[83432]: lost connection after >>>> CONNECT from adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> Jan 18 18:20:54 newmail postfix/smtpd[83432]: disconnect from >>>> adsl-99-98-44-85.dsl.lsan03.sbcglobal.net[99.98.44.85] >>>> >>>> >>>> The client which is using Apple Mail seems to have persistent problem with >>>> his e-mail. >>>> >>>> I wanted to know what are the symptoms of "SSL_accept error" and "lost >>>> connection after CONNECT" ?? >>>> >>>> Should I inspect my configuration (which seems to work very well beside >>>> this) or is it coming from the net or the client side ? >>>> What would you advise me to further debug this ? >>> >>> 'lost connection after CONNECT' means the far end connected and then >>> disconnected. Maybe the client has a buggy TLS. You can >>> selectively turn off TLS for that client by setting: >>> >>> # main.cf >>> smtpd_discard_ehlo_keyword_address_maps = >>>cidr:/etc/postfix/smtpd_keyword_maps >>> >>> # smtpd_keyword_maps >>> 99.98.44.85 STARTTLS >>> >>> http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps >>> >>> >> >> If I turn off TLS for that specific client and he needs to authenticate >> through TLS (SMTPs) I am not sure this will solve my problem ? >> >> Or am I missing something ? > > > Sorry, I didn't understand this was a client that needed to AUTH. > > Perhaps it would help if you enable port 465 smtps with > tls_wrappermode and allow the client to connect there. This is the case tls_wrappermode is enabled in master.cf Auth works very well. My conf is working for 99% of my clients. Only one guy has problems, but this is the boss !! > > Maybe the client doesn't like your certificate for some reason? If > that's the problem they should get some sort of "untrusted" message. Can it simply lost connexion because of poor link quality ? What are the general reasons ? Thx > > > HTH. > > > -- Noel Jones
Re: Problem with SMTPs SSL_accept error | lost connection after CONNECT
Le 19 janv. 2012 à 02:18, Wietse Venema a écrit : > bsd: >> I wanted to know what are the symptoms of "SSL_accept error" and >> "lost connection after CONNECT" ?? > > The client hangs up when Postfix expects the TLS handshake. > > There was two ways that Postfix provides TLS service. One is STARTTLS > mode (usually TCP port 587), and the other is TLS wrapper mode > (usually TCP port 465). > > Does the client connect to port 587 or to port 465? How do you know > that it connects to this port and not to the other one? I have two firewalls filtering tcp / udp ports. From what I can read on netstat there is nothing listening on port 587. Maybe the client tries to initiate a connexion on this port… but this will surely fails ! newmail ~ --> netstat -an -f inet | grep LISTEN tcp4 0 0 *.2004 *.*LISTEN tcp4 0 0 *.2003 *.*LISTEN tcp4 0 0 *.2002 *.*LISTEN tcp4 0 0 *.2001 *.*LISTEN tcp4 0 0 *.1085 *.*LISTEN tcp4 0 0 *.22 *.*LISTEN tcp4 0 0 *.80 *.*LISTEN tcp4 0 0 *.443 *.*LISTEN tcp4 0 0 127.0.0.1.10025*.*LISTEN tcp4 0 0 8x.9x.2x6.99.465 *.*LISTEN tcp4 0 0 127.0.0.1.465 *.*LISTEN tcp4 0 0 8x.9x.2x6.99.25*.*LISTEN tcp4 0 0 127.0.0.1.25 *.*LISTEN tcp4 0 0 *.993 *.*LISTEN tcp4 0 0 *.143 *.*LISTEN tcp4 0 0 *.995 *.*LISTEN tcp4 0 0 *.110 *.*LISTEN tcp4 0 0 127.0.0.1.10026*.*LISTEN tcp4 0 0 127.0.0.1.10024*.*LISTEN tcp4 0 0 *.3306 *.*LISTEN tcp4 0 0 127.0.0.1.10023*.*LISTEN tcp4 0 0 *.199 *.*LISTEN tcp4 0 0 127.0.0.1.705 *.*LISTEN tcp4 0 0 *.10050*.*LISTEN tcp4 0 0 127.0.0.1.953 *.*LISTEN tcp4 0 0 127.0.0.1.53 *.*LISTEN tcp4 0 0 8x.9x.2x6.99.53*.*LISTEN Maybe I should use STARTTLS instead of the wrapper mode ? What are the pros and cons of each solution ? Can I provide both with the same auth backend mechanism (I use dovecot) ? > > Wietse –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Warning about unused parameters
Hello, Since I have upgraded to 2.9.2 I have the following messages upon startup : > /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused > parameter: vacation_destination_recipient_limit=1 > /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused > parameter: virtual_create_maildirsize=yes > /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused > parameter: virtual_mailbox_extended=yes > /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused > parameter: enable_sasl_authentication=yes The server ends up starting but, I found this quite strange… I am wondering if these parameters are outdated or what is the reason for these messages ? Any idea ? Sincerely yours. G.B. –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Warning about unused parameters
Le 30 avr. 2012 à 10:34, bsd a écrit : > Hello, > > > Since I have upgraded to 2.9.2 > I have the following messages upon startup : > >> /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused >> parameter: vacation_destination_recipient_limit=1 >> /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused >> parameter: virtual_create_maildirsize=yes >> /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused >> parameter: virtual_mailbox_extended=yes >> /usr/local/sbin/postconf: warning: /usr/local/etc/postfix/main.cf: unused >> parameter: enable_sasl_authentication=yes > > > The server ends up starting but, I found this quite strange… > > I am wondering if these parameters are outdated or what is the reason for > these messages ? > > Any idea ? > Furthermore, I can't find any pointer on the config info page about "enable_sasl_authentication" I am using dovecot… with quite "classic" settings; Should I remove the "enable_sasl_authentication" because other parameters such as "smtpd_sasl_auth_enable" are activated ? Is it outdated ? I have more or less the same kind of question regarding "virtual_create_maildirsize" and "virtual_mailbox_extended" I am using dovecot with a MySQL backend and quota are fixed per domain / user in here… Thanks for your answer. > > Sincerely yours. > > G.B. > > > –– > -> Grégory Bernard Director <- > ---> www.osnet.eu <--- > --> Your provider of OpenSource appliances <-- > –– > OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO > –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Warning about unused parameters
Le 30 avr. 2012 à 11:44, Ralf Hildebrandt a écrit : >> >> Furthermore, I can't find any pointer on the config info page about >> "enable_sasl_authentication" > > That is because it doesn't exist :) > >> Should I remove the "enable_sasl_authentication" > > Yes, because it doesn't exist! Ok ! Well sounds quite a good reason… I'll get rid of these then ! I have to say I look quite stupid with my question… but I have been leaving with these parameters for so many years that I couldn't imagine that they didn't even exist ?! ;-) > >> because other parameters such as "smtpd_sasl_auth_enable" are activated >> ? Is it outdated ? > > Could be. > >> I have more or less the same kind of question regarding >> "virtual_create_maildirsize" and "virtual_mailbox_extended" I am using >> dovecot with a MySQL backend and quota are fixed per domain / user in >> here… > > Well, they don't exist. Maybe you were running a patched postfix back > then? > > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebra...@charite.de | http://www.charite.de > –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Re: Warning about unused parameters
Le 30 avr. 2012 à 11:57, Ralf Hildebrandt a écrit : > * bsd : > >> I have to say I look quite stupid with my question… but I have been leaving >> with these parameters for so many years that I couldn't imagine that they >> didn't even exist ?! > > Hey, same thing happened to me. After all, Postfix never warned about > those. But since they didn't work ANYWAY... it's safe to remove them. Done ! Thanks for your help. Muchas gracias. Vielen Dank! > > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebra...@charite.de | http://www.charite.de > –– -> Grégory Bernard Director <- ---> www.osnet.eu <--- --> Your provider of OpenSource appliances <-- –– OSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetOSnetO
Redundant remote server
Hello folks, I am actually working for an African country where the electricity is not as stable as one could expect - even in the infrastructure of the historical telco operator… With all the care that we have been able to devote to this project, stability is still very very limited. So my idea was to create a fully redundant mail server. Ideally I would like people not to have to reconfigure anything on their client and to be able to connect to any resource available online (main African server or the backup one in Europe) - in a seamless way. Mail protocol has solved the issue of "backup" server (secondary MX)… but how can I achieve a real redundant server. Knowing that the "main server" and the "slave" are located 8000 Km away with poor link quality. What would be your aproach to solving this problem. Of course loosing mail is really an issue. Thanks. Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
Re: Redundant remote server
Thank you very much for your answer. I have subscribed to the usenix discussion and have been able to access the documents and read them. Thaugh I think this is very promising for the environement we are working with, It seems to be still a research laboratory project at this stage. I would be very happy to participate… if I had the time / money and the engineers to dedicate to this projet. I am looking for something a bit more practical that will allow me to bypass the eventual problems we might face (such as power down of the hosting facility). In fact we are already facing these problems with a DNS server we have just installed (hopefully It is not primary)… I have already deployed the latest version of Postfix on this system with Postfix Admin / dovecot - but It is totally un-usable because of frequent electricity power-down… So right now my dilema is : --- --> Host these services in Europe (which is not very interesting in the perspective of trying to develop / help my African clients). --> Or host my services in the facility I was granted which is not satisfying at all because It is so unstable… And my clients can't access their mail. Any "other" idea ? Le 24 nov. 08 à 14:24, Wietse Venema a écrit : bsd: Hello folks, I am actually working for an African country where the electricity is not as stable as one could expect - even in the infrastructure of the historical telco operator_ With all the care that we have been able to devote to this project, stability is still very very limited. So my idea was to create a fully redundant mail server. Ideally I would like people not to have to reconfigure anything on their client and to be able to connect to any resource available online (main African server or the backup one in Europe) - in a seamless way. Mail protocol has solved the issue of "backup" server (secondary MX)_ but how can I achieve a real redundant server. Knowing that the "main server" and the "slave" are located 8000 Km away with poor link quality. What would be your aproach to solving this problem. Of course loosing mail is really an issue. To get some ideas, see "TierStore: A Distributed File System for Challenged Networks in Developing Regions" by Michael Demmer, Bowei Du, and Eric Brewer. Technology has a great role to play in developing regions, but we need approaches that can tolerate limited networking and power infrastructure. One promising model is to build applications around a file system interface that provides eventual consistency in these challenged network environments. Our resulting system, TierStore, hides much of the complexity of intermittency and simplifies the deployment of important applications such as email, Web caching, and wiki-based collaboration. http://www.usenix.org/publications/login/2008-06/ And other publications by the same people. Wietse ¯¯¯¯ Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
Re: Redundant remote server
Le 25 nov. 08 à 05:42, ram a écrit : On Mon, 2008-11-24 at 13:04 +0100, bsd wrote: Hello folks, I am actually working for an African country where the electricity is not as stable as one could expect - even in the infrastructure of the historical telco operator… With all the care that we have been able to devote to this project, stability is still very very limited. So my idea was to create a fully redundant mail server. Ideally I would like people not to have to reconfigure anything on their client and to be able to connect to any resource available online (main African server or the backup one in Europe) - in a seamless way. Mail protocol has solved the issue of "backup" server (secondary MX)… but how can I achieve a real redundant server. Knowing that the "main server" and the "slave" are located 8000 Km away with poor link quality. Why do you want to have a master-slave ? Hire services of a Mail Server (dedicated or shared .. depending on your budget ) wherever bandwidth/reliability is good. May even be in a different country All the Anti-spam / anti-virus happens on the Remote server and from there pull all mails to a local server using uucp ( yes it still works excellent ) whenever you have power and bandwidth Route the outgoing mails too the same way This is the same idea used by many places over here too. Power many not be the issue, but reliable bandwidth is still a real challenge in rural places Thanks Ram There couple of good reasons for trying to host that in the country: 1. Have a look at my ping statistics : ns0 15:46:55 ~ -> ping 87.xx.yyy.98 PING 87.xx.yyy.98 (87.xx.yyy.98): 56 data bytes 64 bytes from 87.xx.yyy.98: icmp_seq=0 ttl=53 time=1057.235 ms 64 bytes from 87.xx.yyy.98: icmp_seq=1 ttl=53 time=1070.025 ms 64 bytes from 87.xx.yyy.98: icmp_seq=2 ttl=53 time=1120.669 ms 64 bytes from 87.xx.yyy.98: icmp_seq=3 ttl=53 time=1112.328 ms 64 bytes from 87.xx.yyy.98: icmp_seq=4 ttl=53 time=1136.726 ms 64 bytes from 87.xx.yyy.98: icmp_seq=5 ttl=53 time=1193.211 ms 64 bytes from 87.xx.yyy.98: icmp_seq=6 ttl=53 time=1208.738 ms 64 bytes from 87.xx.yyy.98: icmp_seq=7 ttl=53 time=1197.660 ms 64 bytes from 87.xx.yyy.98: icmp_seq=8 ttl=53 time=1202.332 ms 64 bytes from 87.xx.yyy.98: icmp_seq=9 ttl=53 time=1133.286 ms 64 bytes from 87.xx.yyy.98: icmp_seq=10 ttl=53 time=1127.434 ms 64 bytes from 87.xx.yyy.98: icmp_seq=11 ttl=53 time=1121.080 ms 64 bytes from 87.xx.yyy.98: icmp_seq=12 ttl=53 time=1094.035 ms 64 bytes from 87.xx.yyy.98: icmp_seq=13 ttl=53 time=1113.557 ms 64 bytes from 87.xx.yyy.98: icmp_seq=14 ttl=53 time=1104.846 ms ^C --- 87.xx.yyy.98 ping statistics --- 16 packets transmitted, 15 packets received, 6.2% packet loss round-trip min/avg/max/stddev = 1057.235/1132.877/1208.738/45.834 ms This is a typical ping test from the African country in question to the place where services might be hosted. The quality of the service is not very good with an average 6% pacquet lost. And very lonf delay (more than 1sec). The delay will be "ok" the quality is not so ok - because if you try to offer any crypted mail services (SSL / TLS) the delay might rise very fast due to packet lost… 2. Developing this country implies trying to host services in the country and maintain services localy. 3. Local presence of the services will be helpful to provide quality e- mail, including SSL / TLS encrypted transport for more confidential exchange. These are the main resons. Which I found quite good, even if there is a high price to be paid at first… ¯¯¯¯¯¯¯¯ Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail"
