Re: question about auth, smtpd and roundcube
The underlying reason is that I am using a very small machine (and AMD-350), which I have set-up to be fanless., and which is running, appart from the mail server for my family, a couple of webservers, owncloud' instances, etc. So, I thought that I could free it from some work by disabling the encryption in the roundcube. Regards! Felix On Friday 21 June 2013 22:17:49 b...@bitrate.net wrote: > On Jun 21, 2013, at 03.50, Felix Rubio Dalmau wrote: > > Sorry for disturbing you, Ben > > > > Thank you for your answer, but there is one point I don't fully get: If I > > > > set up an smtp [25] to offer encryption without auth, a submission [587] > > to > > require encryption and auth, and I want roundcube to access the mail > > server > > with auth but without encryption I am stuck at the same point, right? > > > > Finally, I have configured smtp [25] to offer encryption, and auth only > > > > under tls. I have also set up a submission [587] without encryption, > > requiring auth, for roundcube. Finally I have closed port 587 using > > iptables, so can be used only through the loopback interface. > > let's please keep the discussion on the list, so others may participate. > > the key here is the "I want roundcube to access the mail server with auth > but without encryption". why bother? roundcube happily performs > encryption just fine, it hurts nothing to do it, and it obviates the need > for unnecessary special treatment. > > you should not be offering auth on port 25, encryption or not. we don't > need to get into all of the corner cases or special use cases, but far and > away, for the average environment, auth is for clients, and clients are to > use port submission/587. if you're using submission/587 for roundcube only > [as you seem to indicate], then why go to all of the trouble to > intentionally disable encryption when it works just fine? > > -ben
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 2013-06-21 Fri 22:08 PM |, Jeroen Geilman wrote: > > > >main.cf: > >myorigin = $mydomain > >mydestination = localhost.$mydomain > > No. If the destination you use in virtual_alias_maps is @localhost, > then THAT must be in mydestination. > Postfix is quite literal. > > mydestination = localhost > append_dot_mydomain = no > > Or, if you wish to follow Victor's advice, qualify all aliases with > "@localhost.$mydomain" instead. > But that's just more typing than I need. > > >It seems the aliases file is not used. > > Of course it is used, for any destinations in $mydestination. > You did not put "localhost" in $mydestination. > Superbly simple config Jeroen, unfortunately it doesn't work for me - yet. main.cf: myorigin = $mydomain mydestination = localhost append_dot_mydomain = no virtual_alias_domains = example.com virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map sender_canonical_maps = btree:$config_directory/canonical.map masquerade_domains = $mydomain, $virtual_alias_domains remote_header_rewrite_domain = sender.domain.incomplete alias_maps = btree:$config_directory/aliases mail_spool_directory = /var/mail/ mailbox_transport = lmtp:unix:private/dovecot-lmtp canonical.map: jb4356 joe.blo...@example.com jb8921 jane.blos...@example.com ... ... virtual_alias_maps.map: # accept mail for postmaster/abuse@[ip.add.ress.es] postmaster postmaster abuse postmaster # (no effect) hostmasterhostmaster # example.com: hostmas...@example.com hostmaster sa...@example.com acct145 i...@example.comacct267 supp...@example.com acct267 ... ... joe.blo...@example.com jb4356 jane.blos...@example.comjb8921 aliases: root: admin-acct MAILER-DAEMON: postmaster abuse: postmaster bin:root daemon: root named: hostmaster nobody: root ... ... NO mail is accepted UNLESS it is virtually aliased with @localhost: *) the aliases file is totally ignored *) without the virtual @localhost, it is: status=bounced (User unknown in virtual alias table) $ uptime | mail -s uptime hostmaster (<--- this is a unix account) Jun 22 11:15:21 server1 postfix/pickup[6298]: 12A1F6764: uid=7432 from= Jun 22 11:15:21 server1 postfix/cleanup[8557]: 12A1F6764: message-id=<20130622101521.12a1f6...@server1.example.com> Jun 22 11:15:21 server1 postfix/qmgr[13148]: 12A1F6764: from=, size=393, nrcpt=1 (queue active) Jun 22 11:15:21 server1 postfix/error[20137]: 12A1F6764: to=, orig_to=, relay=none, delay=0.03, delays=0.02/0/0/0.01, dsn=5.0.0, status=bounced (User unknown in virtual alias table) $ uptime | mail -s uptime hostmas...@example.com Jun 22 11:16:21 server1 postfix/pickup[6298]: 873CF6764: uid=7432 from= Jun 22 11:16:21 server1 postfix/cleanup[8557]: 873CF6764: message-id=<20130622101621.873cf6...@server1.example.com> Jun 22 11:16:21 server1 postfix/qmgr[13148]: 873CF6764: from=, size=393, nrcpt=1 (queue active) Jun 22 11:16:21 server1 postfix/error[20137]: 873CF6764: to=, relay=none, delay=0.03, delays=0.02/0/0/0.01, dsn=5.0.0, status=bounced (User unknown in virtual alias table) $ uptime | mail -s uptime daemon (<--- this is in aliases, for root) Jun 22 11:54:13 server1 postfix/pickup[24295]: 1EC8F67DC: uid=7432 from= Jun 22 11:54:13 server1 postfix/cleanup[15996]: 1EC8F67DC: message-id=<20130622105413.1ec8f6...@server1.example.com> Jun 22 11:54:13 server1 postfix/qmgr[7561]: 1EC8F67DC: from=, size=389, nrcpt=1 (queue active) Jun 22 11:54:13 server1 postfix/error[23896]: 1EC8F67DC: to=, orig_to=, relay=none, delay=0.26, delays=0.14/0.06/0/0.06, dsn=5.0.0, status=bounced (User unknown in virtual alias table) It seems that if the machine's own domain is virtual (with or without @localhost virtual aliases), aliases is ignored. Therefore, for the machine's domain name to be virtual, everything in alaises must be moved to the virtual alias map & appended with unix-account@localhost. I don't want 'root, daemon, nobody,...' items to be publicly route-able. Stan's idea of a plain canonical domain & rejecting specific Unix accounts via smtpd_recipient_restrictions check_recipient_access reject_system_accounts.map works. Thoughts welcome, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: myhostname and PTR
Thank you for the replys, they are very helpful. I "own" this domain, and the danish handler of .dk allows all settings in DNS to be altered, but the hosting provider does not. All records besides PTR is within my control at the provider, so I guess it's a design decision they have taken, and I will contact them about this. Cheers
Re: timed out while receiving the initial server greeting message
Selcuk Yazar: > Hi, > > How can i solve this message. when i see this message in mailq, our mail > delivery getting too slow. is windows_tcp_scaling thing work ? Make a network recording for a connection to the problem site. For example, see http://www.postfix.org/DEBUG_README.html#sniffer Someone on the mailing list can explain what the output means. Wietse
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On 6/22/2013 6:13 AM, Craig R. Skinner wrote: ... > Stan's idea of a plain canonical domain & rejecting specific Unix > accounts via smtpd_recipient_restrictions check_recipient_access > reject_system_accounts.map works. Everyone whose replied in this thread knows and understands aliasing much better than I do. The only thing of value I think I can add at this point is that using a recipient restriction gives you some flexibility, maybe a greater degree of control. For one you can tailor the reject code and reason text on a per address basis in the map file. You can also use the same map to arbitrarily reject mail for any address in the future, should the need arise, though the latter is pretty quick to fix up in a pinch. Having the map in place simply makes it a little quicker. But the key is really that you're directly specifying which addresses for which you will reject inbound mail via smtp. There's no guesswork no matter what's going on in the back end WRT aliasing. -- Stan
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
On Sat, Jun 22, 2013 at 12:13:16PM +0100, Craig R. Skinner wrote: > > >main.cf: > > >myorigin = $mydomain > > >mydestination = localhost.$mydomain Notice the exact form of the above (IIRC that was my suggestion). > > No. If the destination you use in virtual_alias_maps is @localhost, > > then THAT must be in mydestination. > > Postfix is quite literal. > > > > mydestination = localhost > > append_dot_mydomain = no Whoever said that does not know what they are talking about. With the default of "append_dot_mydomain = yes", Postfix will replace "user@localhost" with "user@localhost.$mydomain" before performing recursive lookups with virtual_alias_maps. > > Or, if you wish to follow Victor's advice, qualify all aliases with > > "@localhost.$mydomain" instead. No, that can't be done literally, one would have to replace "$mydomain" with the actual value. To quote Dr. Seuss: I meant what I said and I said what I meant. > Superbly simple config Jeroen, unfortunately it doesn't work for me - > yet. > > main.cf: > myorigin = $mydomain > mydestination = localhost mydestination = localhost.$mydomain > append_dot_mydomain = no append_dot_mydomain = yes > remote_header_rewrite_domain = sender.domain.incomplete remote_header_rewrite_domain = address.invalid The ".invalid" TLD is IANA reserved for invalid domain names. If these aliases are to be effective the RHS needs to be in a valid domain, your choices are "localhost" or "example.com". The former will perform local(8) delivery directly without generating a new queued message with the expanded recipients. The latter will do indirect (new queue file) delivery because example.com is not in mydestination. > virtual_alias_maps.map: > # accept mail for postmaster/abuse@[ip.add.ress.es] > postmaster postmaster Never leave RHS domain unset in virtual_alias_maps. Replace the RHS with postmaster@localhost (which punts the mail to local(8) for aliases(5) expansion) or with the full addresses of users receiving postmaster mail. The LHS can only be left unqualified if the virtual alias domain is equal to $myorigin. Otherwise, it too MUST be an FQDN. Thus, either: # Actual expansion in local(8) aliases(5). Not recommended. # postmas...@example.compostmaster@localhost or: # Actual expansion in local(8) aliases(5). Preferred: # postmas...@example.comus...@example.com, us...@example.com, ... > abuse postmaster Here: ab...@example.com postmas...@example.com > hostmas...@example.com hostmaster Same as postmaster! > sa...@example.com acct145 sa...@example.com acct...@example.com > joe.blo...@example.com jb4356 joe.blo...@example.com jb4356@localhost > jane.blos...@example.comjb8921 jane.blos...@example.comjb8921@localhost Use virtual(5) for ALL address -> address mappings, with only addresses that represent final mailboxes listed as account@localhost. Use aliases(5) sparingly, only for "|command" aliases (try to avoid these anyway) or ":include:" lists. The aliases(5) file is a Sendmail compatibility feature, whose features are best remapped onto virtual(5) (address to address mappings controlled by the administrator) and .forward files (own address to address or command mappings possibly controlled by shell users). -- Viktor.
Re: Local UNIX accounts, aliasing & rejecting mail to non-public UNIX accounts
I agree with Viktor's description: /etc/postfix/main.cf: # The domain that users are aliased to: mydestination = localhost localhost.$mydomain # The domain in DNS that you receive mail for: vitual_alias_maps = example.com # The alias mapping from "DNS" domain name to UNIX system accounts: virtual_alias_maps = hash:/etc/postfix/virtual /etc/postfix/virtual: # All right-hand addresses have @localhost postmas...@example.com postmaster@localhost us...@example.com unix-user1@localhost us...@example.com unix-user2@localhost # Legacy sendmail-style aliases: /etc/aliases: # Here, no @domain in LHS or RHS. postmaster: unixaccount abuse: unixaccount There is no need for this thread to drag on for so much time. Wietse
