Postfix as intermediary server
Hi, list. The mail server servers some web-applications (e-shops). I use virtual_alias_maps to maps virtual boxes like i...@my-shop.com to real box like blabla...@gmail.com, so when customer sends e-mail to i...@my-shop.com we can read this message from gmail account. But what about replay to customers and have something like threads. E.g. I replay to customer's message but customer receive message as though it has been sent from i...@my-shop.com, not from blabla...@gmail.com. Any ideas? -- Vitaly
Re: Postfix as intermediary server
On Sat, 17 Jan 2015 14:14:47 +0200 wishmaster wrote: > The mail server servers some web-applications (e-shops). I use > virtual_alias_maps to maps virtual boxes like i...@my-shop.com to real > box like blabla...@gmail.com, so when customer sends e-mail to > i...@my-shop.com we can read this message from gmail account. But what > about replay to customers and have something like threads. E.g. I > replay to customer's message but customer receive message as though > it has been sent from i...@my-shop.com, not from blabla...@gmail.com. > > > Any ideas? > ask gmail/google why they did it or use mail client and not using their webmail interface.
Re: Postfix as intermediary server
It used to be possible. In GMail, go to Settings > Accounts and Import and look at the "Send mail as" section and see if you can set it up. This used to work, but for my domain now does not in the way it used to and it wants to relay through my own domain's mail server. This is not good news as I wanted to relay my domain through GMail's SMTP server as I have a dynamic IP. If it is OK for you, you could set up postfix to relay back through you but I suspect you don't want to do that unless you can then relay out through another mail server such as your ISP's (in which case you may be able to relay direct from GMail to your ISP's SMTP servers. As it used to work you could enquire of Google how to make it happen again but it may now be a paid-for service. Regards, Nick On 17/01/2015 12:29, Koko Wijatmoko wrote: On Sat, 17 Jan 2015 14:14:47 +0200 wishmaster wrote: The mail server servers some web-applications (e-shops). I use virtual_alias_maps to maps virtual boxes like i...@my-shop.com to real box like blabla...@gmail.com, so when customer sends e-mail to i...@my-shop.com we can read this message from gmail account. But what about replay to customers and have something like threads. E.g. I replay to customer's message but customer receive message as though it has been sent from i...@my-shop.com, not from blabla...@gmail.com. Any ideas? ask gmail/google why they did it or use mail client and not using their webmail interface.
Re: Conditional/soft smtpd restrictions
Hello, -Original Message- From: li...@rhsoft.net Sent: Saturday, January 17, 2015 7:29 AM > Actually the set I have is surprisingly effective and also surprisingly > good in keeping FPs low -- much, much better than anything I saw from SA > and DSPAM, and with virtually no server or management overhead. That's > why I only want a controlled workaround for misconfigured senders just setup "rbldnsd" and use "permit_dnswl_client" with your own whitelist, that way you can even create different return values of your whitelist and place them to override different stages of your restricitions by trust-levels Actually access maps can be used for whitelists, should be easier. But in my scenario, the problem senders are not known in advance and cannot be predicted. Best wishes Eugene
Re: Conditional/soft smtpd restrictions
Am 18.01.2015 um 00:00 schrieb Eugene R: -Original Message- From: li...@rhsoft.net Sent: Saturday, January 17, 2015 7:29 AM > Actually the set I have is surprisingly effective and also surprisingly > good in keeping FPs low -- much, much better than anything I saw from SA > and DSPAM, and with virtually no server or management overhead. That's > why I only want a controlled workaround for misconfigured senders just setup "rbldnsd" and use "permit_dnswl_client" with your own whitelist, that way you can even create different return values of your whitelist and place them to override different stages of your restricitions by trust-levels Actually access maps can be used for whitelists, should be easier but can be forged, everybody can use any envelope as long the sending domain don't use SPF *and* the RCPT server don't check SPF records you can't fake a TCP source address the same way so if you use access maps i only need to guess which senders bypass your restrictions adn just use them as envelope But in my scenario, the problem senders are not known in advance and cannot be predicted then you can simply not use restrictions which are producing false positives in your environment
fatal: no SASL authentication mechanisms
I need help with using dovecot sasl. I get /var/spool/postfix/private/auth failed: No such file or directory but the file exists. # ls -l /var/spool/postfix/private/auth srw-rw-rw- 1 postfix postfix 0 Jan 17 21:58 /var/spool/postfix/private/auth I've verified docotsasl works (I think): # doveadm auth -a /var/spool/postfix/private/auth test_user Password: passdb: test_user auth succeeded extra fields: user=test_user These are the relevant log entries: /var/log/mail.err postfix/smtpd[1704]: fatal: no SASL authentication mechanisms /var/log/mail.log postfix/smtpd[1519]: warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory /etc/postfix/master.cf submission inet n - - - - smtpd -v -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING /etc/postfix/main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_auth_enable = yes #smtpd_sasl_security_options = noanonymous #smtpd_sasl_local_domain = smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
Re: fatal: no SASL authentication mechanisms
On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote: > /var/log/mail.log > postfix/smtpd[1519]: warning: SASL: Connect to > /var/spool/postfix/private/auth failed: No such file or directory > > /etc/postfix/master.cf > submission inet n - - - - smtpd -v > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING Just another chroot victim, -- Viktor.
Re: fatal: no SASL authentication mechanisms
On 01/17/15 22:55, Viktor Dukhovni wrote: > On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote: > >> /var/log/mail.log >> postfix/smtpd[1519]: warning: SASL: Connect to >> /var/spool/postfix/private/auth failed: No such file or directory >> >> /etc/postfix/master.cf >> submission inet n - - - - smtpd -v >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> -o milter_macro_daemon_name=ORIGINATING > Just another chroot victim, > Oh. Is Postfix and/or Dovecot chrooted by default? Can a message be output in the info log?
Re: fatal: no SASL authentication mechanisms
Am 18.01.2015 um 05:40 schrieb James Lockie: On 01/17/15 22:55, Viktor Dukhovni wrote: On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote: /var/log/mail.log postfix/smtpd[1519]: warning: SASL: Connect to /var/spool/postfix/private/auth failed: No such file or directory /etc/postfix/master.cf submission inet n - - - - smtpd -v -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING Just another chroot victim, Is Postfix and/or Dovecot chrooted by default? no, the default in master.cf is an explicit "n" Can a message be output in the info log? better make a bugreport at your distribution https://www.google.at/search?q=postfix+debian+chroot+problems
Re: fatal: no SASL authentication mechanisms
On January 17, 2015 11:58:16 PM EST, "li...@rhsoft.net" wrote: > >Am 18.01.2015 um 05:40 schrieb James Lockie: >> On 01/17/15 22:55, Viktor Dukhovni wrote: >>> On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote: >>> /var/log/mail.log postfix/smtpd[1519]: warning: SASL: Connect to >/var/spool/postfix/private/auth failed: No such file or directory /etc/postfix/master.cf submission inet n - - - - smtpd -v -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING >>> Just another chroot victim, >>> >> Is Postfix and/or Dovecot chrooted by default? > >no, the default in master.cf is an explicit "n" > >> Can a message be output in the info log? > >better make a bugreport at your distribution >https://www.google.at/search?q=postfix+debian+chroot+problems Assuming this is Debian, there's no bug report needed. It's an intentional maintainer choice and not a bug. Scott K
Re: fatal: no SASL authentication mechanisms
On Sun, Jan 18, 2015 at 12:02:24AM -0500, Scott Kitterman wrote: > >better make a bugreport at your distribution > >https://www.google.at/search?q=postfix+debian+chroot+problems > > Assuming this is Debian, there's no bug report needed. It's an intentional > maintainer choice and not a bug. I think the "intentional maintainer choice" has long proved unwise. So though not a bug, it is definitely misfeature. Since the default chroot is far from seamless: - Lost logs - Milter socket problems - SASL problems - DNS resolution problems - ... If the level of integration were such that none of these issues were to ever happen, I'd accept this as a valid maintainer choice. Given that problems come up all the time, I rather see this is a maintainer mistake that should finally be corrected. Chroot is for experts willing and able to figure out what needs to be done to get it working. As a default Debian/Ubuntu configuration I think it just needlessly gives Postfix on these systems a bad name. -- Viktor.
