newsreader and subscription
Hi, i'm using a Newsreader to read this list (via news.gname.org). But afaik i have to be subscribed to write to this list. And if i'm subscribed i will receive every post via email too, so i receive it twice. Is there a way to be subscribed without "receving" posts to my mail address? kind regards, Georg
Re: Make smtpd/Postscreen compatible with load balancers
Dear I have played with DNS and MX but the problem is DNS did not care about servers load and if servers have a huge queue. It just balance to next MX only if the server did not respond. Load-balancing is a cool feature that take care on the server health. Especially if you add services on the server such as Spamassassin, backup mails, MDA... Wietse, i copy the founder of HaProxy (Willy Tarreau) in this mail in order to introduce him and see if he can help you implementing such protocol in PostScreen/smtpd. Best regards. Le 27/05/2012 15:25, Wietse Venema a écrit : David Touzeau: Dear We are facing an problem that we cannot resolve... Our main goal is to implement a load-balancer in front of Postfix (HaProxy). We have made a discuss with HaProxy founder in order to implement the XCLIENT protcol but this is difficult for him to implement such protocol. FYI nginx implements XCLIENT (and more). But it does not matter, since postscreen has no proxy support. In other way it seems that PostScreen is not really compatible with the proxy protocol. First, there needs to be a configuration parameter that tells postscreen what kind of proxy command will be prepended to the client's SMTP stream. /etc/postfix/main.cf: # Is there a better name than "proxy protocol"? postscreen_proxy_protocol = whatever With this, postscreen will drop connections that fail to conform to the configured protocol. Regardless of command format details, if the proxy prepends a command to the client's SMTP stream, then postscreen must use unbuffered I/O to read that command. If buffering were turned on, the buffering layer could read past the proxy's and eat up part of the client input kind-of like CVE-2011-0411. A rough estimate of what this requires: - A new main.cf parameter and documentation. - A way to turn off buffering on VSTREAMs. Alternative: use low-level read system calls and re-invent VSTREAM timeout/etc. error handling. Either this may take a dozen or so lines of code. - A new postscreen code module with generic hook to prepend proxies. - An event-driven loop that reads the proxy command one character at a time until, length exceeded, EOF, time limit, or other error. Another dozen lines. - A proxy command parser that does all the necessary sanity checks (valid address syntax, numerical TCP ports in the range 1..65535), no missing or extra fields. Another dozen lines. - Reuse the existing postscreen data structures that are now filled with endpoint information from getpeername() and getsockname(). Wietse
Re: Make smtpd/Postscreen compatible with load balancers
On May 28, 2012, at 10:26, David Touzeau wrote: > I have played with DNS and MX but the problem is DNS did not care about > servers load and if servers have a huge queue. > It just balance to next MX only if the server did not respond. > Load-balancing is a cool feature that take care on the server health. > Especially if you add services on the server such as Spamassassin, backup > mails, MDA... Did you read (and understand) Victor's example? Did you test with multiple servers that had the same preference in their MX record? If they do not have the same preference, the server with the lowest preference value will always be preferred, and failover to the others will indeed only happen when that server is down. -- If you operate at scale, you build out your SMTP infrastructure not just in width, but also in depth; 1) Mail exchangers. Your first 'line of defense'. These show up in your MX records, and run postscreen to fend off bot traffic and the like. They reject everything you know you're not going to accept, BEFORE the queue. How much depends on your profile, but in our case at more than 70% of connections never makes it to the queue. Everything that is accepted is passed on immediately. These do not have any local user mailboxes, and do not do any significant amount of content filtering. They should never have significant amounts of mail in the queue. 2) Mail routing. Where does this message go? Does it need to be archived, copied, rerouted? 3) Content filtering. This is where Spamassassin runs, for example. Spam is marked, everything is passed on. Nothing is bounced, ever. 4) Mailbox server. Accepts the message and sorts them into local folders, where they are stored on disk. This is where POP3/IMAP daemons run to serve users accessing their mailboxes. 5) Submission server. This is what your clients talk to to send their outgoing mail. Requires authentication, runs on port 587, and does not need postscreen. May do some basic checks, but passes messages on as quickly as possible. Should never have much of a queue. 6) Relay servers. These are the servers that talk to the rest of the internet, for outgoing mail. Since you have little control over the availability and load of the servers you are communicating with, mail may be in the queue here for a while, up to several days. -- In most setups, several of these roles can be combined; MX and routing generally go together, and can take care of outgoing relay as well. Content filtering and submission can run on the mailbox servers. But really, find the real bottleneck. You should not need to load balance postscreen, and it's quite likely that it is not the right place to start optimizing. Where are you maxing out? CPU, memory, disk? Is it a single customer that can be split off to a seperate box, perhaps? Cya, Jona -- > Le 27/05/2012 15:25, Wietse Venema a écrit : >> David Touzeau: >>> Dear >>> >>> We are facing an problem that we cannot resolve... >>> Our main goal is to implement a load-balancer in front of Postfix (HaProxy). >>> We have made a discuss with HaProxy founder in order to implement the >>> XCLIENT protcol but this is difficult for him to implement such protocol. >> FYI nginx implements XCLIENT (and more). But it does not matter, >> since postscreen has no proxy support. >> >>> In other way it seems that PostScreen is not really compatible with the >>> proxy protocol. >> First, there needs to be a configuration parameter that tells >> postscreen what kind of proxy command will be prepended to the >> client's SMTP stream. >> >> /etc/postfix/main.cf: >> # Is there a better name than "proxy protocol"? >> postscreen_proxy_protocol = whatever >> >> With this, postscreen will drop connections that fail to conform >> to the configured protocol. >> >> Regardless of command format details, if the proxy prepends a command >> to the client's SMTP stream, then postscreen must use unbuffered >> I/O to read that command. If buffering were turned on, the buffering >> layer could read past the proxy's and eat up part of the >> client input kind-of like CVE-2011-0411. >> >> A rough estimate of what this requires: >> - A new main.cf parameter and documentation. >> - A way to turn off buffering on VSTREAMs. Alternative: use low-level >> read system calls and re-invent VSTREAM timeout/etc. error handling. >> Either this may take a dozen or so lines of code. >> - A new postscreen code module with generic hook to prepend proxies. >> - An event-driven loop that reads the proxy command one character >> at a time until, length exceeded, EOF, time limit, or >> other error. Another dozen lines. >> - A proxy command parser that does all the necessary sanity checks >> (valid address syntax, numerical TCP ports in the range 1..65535), >> no missing or extra fields. Another dozen lines. >> - Reuse the existing postscreen data structures that are now filled >> with endpoint information from getpeern
postfix and DNs server
Hi all I am using postfix 2.8.4 on centos 5.8 and recently I installed bind9 on the same server to have my own DNS server. I didn't change MX record of mail server as I am still testing configuration and newbie but I noticed that outgoing mails stopped being delivered and I don't know why as I don't change anything in postfix or MX records what may cause that? Regards
Re: postfix and DNs server
Am 28.05.2012 13:57, schrieb Amira Othman: > I am using postfix 2.8.4 on centos 5.8 and recently I installed bind9 on the > same server to have my own DNS server. I didn't change MX record of mail > server as I am still testing configuration and newbie but I noticed that > outgoing mails stopped being delivered and I don't know why as I don't > change anything in postfix or MX records what may cause that? * you do not provide any informations * our crystal ball does not work however, if your OUTGOING mail stopped it sounds like /etc/resolv.conf points to your local nameserver which does not work signature.asc Description: OpenPGP digital signature
Re: postfix and DNs server
Amira Othman: > Hi all > > I am using postfix 2.8.4 on centos 5.8 and recently I installed bind9 on the > same server to have my own DNS server. I didn't change MX record of mail > server as I am still testing configuration and newbie but I noticed that > outgoing mails stopped being delivered and I don't know why as I don't > change anything in postfix or MX records what may cause that? Postfix logs all attempts to send or receive mail, whether or not these attempts are successful. I suggest you look there first. Wietse
RE: postfix and DNs server
Amira Othman: > Hi all > > I am using postfix 2.8.4 on centos 5.8 and recently I installed bind9 on the > same server to have my own DNS server. I didn't change MX record of mail > server as I am still testing configuration and newbie but I noticed that > outgoing mails stopped being delivered and I don't know why as I don't > change anything in postfix or MX records what may cause that? Postfix logs all attempts to send or receive mail, whether or not these attempts are successful. I suggest you look there first. Wietse This is log error from=, size=11908, nrcpt=1 (queue active) May 28 10:20:28 cairosource postfix/smtp[32092]: AC8596E684AB: to=, relay=mx01.hmc1.comcast.net[76.96.53.13]:25, delay=2.1, delays=1.9/0.02/0.24/0, dsn=4.0.0, status=deferred (host mx01.hmc1.comcast.net[76.96.53.13] refused to talk to me: 554 imta01.westchester.pa.hmc1.comcast.net bizsmtp x.x.x.x Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more information, refer to:http://worknetkc.st.comcastsupport.com/sdccommon/asp/defcontent_view.asp? ssfromlink=true&sprt_cid=bb859780-1131-4fbf-b307-4798d1e628f0) My resolve.conf contains just nameserver 127.0.0.1 and I didn't setup reverse DNS yet. But MX record of this domain is not on my DNS it's another DNS server.
Re: postfix and DNs server
Am 28.05.2012 14:22, schrieb Amira Othman: > from=, size=11908, nrcpt=1 (queue active) > May 28 10:20:28 cairosource postfix/smtp[32092]: AC8596E684AB: > to=, relay=mx01.hmc1.comcast.net[76.96.53.13]:25, > delay=2.1, delays=1.9/0.02/0.24/0, dsn=4.0.0, status=deferred (host > mx01.hmc1.comcast.net[76.96.53.13] refused to talk to me: 554 > imta01.westchester.pa.hmc1.comcast.net bizsmtp x.x.x.x Comcast requires that > all mail servers must have a PTR record with a valid Reverse DNS entry. > Currently your mail server does not fill that requirement. did you read the message? your outgoing server seems not to have a proper PTR it would be really helpful if you provide informations * what is your domain * what public IP has your outgoing MTA > My resolve.conf contains just nameserver 127.0.0.1 this is bad in context "recently I installed bind9 on the same server"! why do you use a TESTING nameservr for your MTA? > and I didn't setup reverse DNS yet if your MTA has no reverse DNS outside you can not expect that someone accepts mail from you > But MX record of this domain is not on my DNS > it's another DNS server MX rceord has really NOTHING to do with outgoing mail! signature.asc Description: OpenPGP digital signature
Re: postfix and DNs server
Amira Othman: > Comcast requires that all mail servers must have a PTR record with > a valid Reverse DNS entry. Currently your mail server does not > fill that requirement. For more information, refer to: > http://worknetkc.st.comcastsupport.com/sdccommon/asp/defcontent_view.asp? > ssfromlink=true&sprt_cid=bb859780-1131-4fbf-b307-4798d1e628f0) You need to set up a PTR record for your server's IP address, an A record that resolves the name in the PTR record to your server's IP address, and perhaps Postfix needs to be configured to send "EHLO" with the name in the PTR record. All this has nothing to do with the MX record. Wietse
Re: Postfix SMTP Client Segfaults over TLS
Thanks for the response Wietse, most appreciated. Daniel Sutcliffe wrote: >> I'm having a very similar problem here on CentOS 6 - unfortunately moving or >> removing the TLS session caches and restarting postfix is not fixing my >> problem >> at all. Coincidently the openssl package was updated the day before the >> problem >> started. >> postfix 2.6.6-2.2.el6_1 >> openssl 1.0.0-20.el6_2.4 Wietse Venema wrote: > Was Postfix compiled for openssl 1.0.0? If it was built for 0.9.mumble, > then the warranty is void and all bets are off. CentOS 6 has always been OpenSSL 1.0.0 AFAIK and therefore the postfix version was certainly originally built against this. Trawling back through the logs I can see that on May 16 openssl was upgraded from 1.0.0-20.el6_2.3 to 1.0.0-20.el6_2.4 - and there had been no issues running the postfix 2.6.6-2.2.el6_1 package with that previous package build of openssl. I have now tried stopping postfix, downgrading my openssl package back to this previous version, deleting the TLS session caches, and starting postfix again and the same problem is occurring - which would infer to me that it isn't an OpenSSL package version which caused the problem - and maybe the upgrade of this package in the same time-frame as when the problem started occurring may be a bit of a red herring :( The only other change in system which would seem to be even slightly related was that the kernel was updated and a reboot occurred just before the errors started to occur. I am contemplating going back to the previous version of the kernel but would like to take advice from those more experienced and knowledgeable in postfix than myself as to if this might possibly have caused the issue, or if there are any other diagnostics I can do before this ... the server runs a live Web site so downtime for a reboot is something I want to avoid and/or timetable during a quiet period. Any pointers gratefully received, Cheers /dan -- Daniel Sutcliffe
Re: Postfix SMTP Client Segfaults over TLS
Daniel Sutcliffe: > I have now tried stopping postfix, downgrading my openssl package back > to this previous version, deleting the TLS session caches, and > starting postfix again and the same problem is occurring - which would > infer to me that it isn't an OpenSSL package version which caused the > problem - and maybe the upgrade of this package in the same time-frame > as when the problem started occurring may be a bit of a red herring :( > > The only other change in system which would seem to be even slightly > related was that the kernel was updated and a reboot occurred just > before the errors started to occur. I am contemplating going back to I suggest looking at % ldd /usr/libexec/postfix/smtp and examining all the libraries referenced. Perhaps the update has introduced a new library-to-library dependency, such as a new LDAP library dependency on a different SASL library than Postfix wants. Dependencies may also be introduced via nsswitch.conf; those don't show up in ldd output. Kernel APIs don't change randomly. Wietse
exchange like feature for always_bcc?
Hello, I've got a mail server (A) configured to always_bcc to another computer (B). Fine. My problem is the following. Let's say the original email had 10 recipients. When "A" hands the email to "B" it preserves the MAIL FROM part, however it drops all the 10 recipients in the RCPT TO phase and replaces them with 1 email address: what I configured for always_bcc. My question is that is it possible to preserve the 10 recipients, and pass this info somehow to "B"? I could think of an XFORWARD like solution, eg. XRECIPIENT 220 server.example.com ESMTP Postfix EHLO client.example.com 250-server.example.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-XFORWARD NAME ADDR PROTO HELO 250-XRECIPIENT EMAIL 250 8BITMIME XRECIPIENT EMAIL=foo@bar XRECIPIENT EMAIL=fu@bar ... 250 Ok Another approach can be what MS Exchange uses: it rewrites the email and adds another MIME part, eg. Date: Mon, 28 May 2012 13:50:57 + X-MS-Journal-Report: --_35de6223-0a94-4d9e-895d-7dea50fb1c40_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: foo@bar Subject: the subject from the sent email Message-Id: Recipient: user1@bar Recipient: user2@bar --_35de6223-0a94-4d9e-895d-7dea50fb1c40_ Content-Type: message/rfc822 The reason I could use a feature like this is that an archiving solution sits on "B", and unfortunately parsing the email headers is not an accurate solution to determine who exactly got the message that "B" just archived. Thanks for any help, Albert
Re: exchange like feature for always_bcc?
Kov?cs Albert: > Hello, > >I've got a mail server (A) configured to always_bcc to another >computer (B). Fine. > >My problem is the following. Let's say the original email had 10 >recipients. When "A" hands the email to "B" it preserves the MAIL >FROM part, however it drops all the 10 recipients in the RCPT TO >phase and replaces them with 1 email address: what I configured for >always_bcc. If you want forward to different recipient addresses, then don't use always_bcc. Instead, use recipient_bcc_maps which allows you to specify different addresses for different recipients. /etc/postfix/main.cf: recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc /etc/postfix/recipient_bcc: /^([^@]+)@example\.com$/$1...@otherhost.example.com Wietse
virtual alias problem
many years ago when I switched to postfix, I had a problem with some large, nested aliases in the aliases file - an invalid recipient somewhere in the list would cause a send failure and so the message to the alias would be requeued with the result being that those recipients before the problem would get multiple copies and those after would not get the mail. It was suggested to me at the time to use virtual aliases for the large lists as the recipients in a virtual alias are sent to individually. So I constructed my normal alias file as something like: group_1: user1, user2, user3, etc. group_2: user10, user11, user12, etc. group_3: user20, user21, user22, etc. Then in virtual, I put; all-groups:group_1, group_2, group_3 If there were a problem in group_2, mail to group_1 and group_3 would be properly sent and it was easier to track down the issue with group_2. I'm now moving my mail server within the organization to a new subdomain, but I intend to keep the same mail address scheme we've always used. I copied in my old configuration on the new server, but I'm now getting a failure for the aliases in the virtual file, giving me an error: all-groups unknown user. It's not exactly the same server - I set up a new(er) system in the new location and am trying to switch over services and I just discovered that the virtual aliases were not working on the new one. My old location server is running postfix 2.6.5, the new location is running 2.7.0. My main.cf does not define virtual aliases or domains, I just reference the virtual_alias map file: virtual_alias_maps = hash:/etc/postfix/virtual I have set mydestination to be my desired domain and added in one for the new subdomain. Thanks for any assistance. I've gone through the virtual and local readmes, but I am not seeing the solution. Dirk This message was sent using IMP, the Internet Messaging Program.
Re: virtual alias problem
On Mon, 2012-05-28 at 17:52:24 -0700, Dirk Kleinhesselink wrote: > ... > Then in virtual, I put; > > all-groups:group_1, group_2, group_3 > ... > I'm now moving my mail server within the organization to a new > subdomain, but I intend to keep the same mail address scheme we've > always used. I copied in my old configuration on the new server, but > I'm now getting a failure for the aliases in the virtual file, giving > me an error: all-groups unknown user. Can we see the actual log excerpt? > ... > I have set mydestination to be my desired domain and added in one for > the new subdomain. > > Thanks for any assistance. I've gone through the virtual and local > readmes, but I am not seeing the solution. Can we see the output of 'postconf -n'? Absent additional information, I guess you may find a clue in virtual(5) under TABLE SEARCH ORDER. -- Sahil Tandon
Re: virtual alias problem
On 5/28/2012 8:08 PM, Sahil Tandon wrote: > On Mon, 2012-05-28 at 17:52:24 -0700, Dirk Kleinhesselink wrote: > >> ... >> Then in virtual, I put; >> >> all-groups:group_1, group_2, group_3 I see two possible problems... First, with virtual_alias_maps it is strongly recommended to use fully-qualified addresses and not bare user names. Bare names are supported, but can give unexpected results unless you carefully read the "table search order" of virtual(5). Secondly, the format of virtual_alias_maps does NOT use the ":" separator between the key and the data. With your example above, postfix would expect the user name to be "all-groups:@$myorigin" So your virtual map should resemble: all-gro...@example.com group_1@localhost, group2@localhost, ... If this doesn't help, follow Sahil's advice and provide better information. -- Noel Jones >> ... >> I'm now moving my mail server within the organization to a new >> subdomain, but I intend to keep the same mail address scheme we've >> always used. I copied in my old configuration on the new server, but >> I'm now getting a failure for the aliases in the virtual file, giving >> me an error: all-groups unknown user. > > Can we see the actual log excerpt? > >> ... >> I have set mydestination to be my desired domain and added in one for >> the new subdomain. >> >> Thanks for any assistance. I've gone through the virtual and local >> readmes, but I am not seeing the solution. > > Can we see the output of 'postconf -n'? Absent additional information, > I guess you may find a clue in virtual(5) under TABLE SEARCH ORDER. >
