Re: Postfix and Myvzw.com POP3 email
Good evening fellow Postfix-ers: Here is the end result as I have fixed my problem with my authorization issue and Myvzw.com. First of all, postconf -a indicated that my current install (CND solaris package) did not support Cyrus or Dovecot. This led me to do the following: 1. Downloaded from Sunfreeware.com the SASL 2.1.21 Solaris-sparc package (Please note that there's a symbolic link that is recommended on the Sunfreeware page. Depending on your library location, you need to make this link.) 2. Installed SASL using the pkgadd command 3. Configured SASL using the manual SMTP AUTH Using Cyrus and Postfix By Saul Cisneros. 4. Downloaded the latest version (2.7.2) of postfix. In compiling v2.7.2, it is extremely important to pass the correct arguments to your compiler. I used the following commands for Solaris 10: # make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL-I/usr/include/sasl -I/usr/local/include/sasl -I/usr/local/lib/sasl2 AUXLIBS=-L/usr/local/lib -lsasl2 # make # make install After starting the new postfix up for the first time, I was seeing the following errors when first sending mail from my phone to my postfix server: Dec 29 20:16:59 server-new postfix/smtpd[1560]: [ID 197553 mail.info] connect from 49.sub-174-252-167.myvzw.com[174.252.167.49] Dec 29 20:16:59 server-new postfix/smtpd[1560]: [ID 947731 mail.warning] warning: SASL authentication failure: no secret in database Dec 29 20:16:59 server-new postfix/smtpd[1560]: [ID 947731 mail.warning] warning: 49.sub-174-252-167.myvzw.com[174.252.167.49]: SASL CRAM-MD5 authentication failed: authentication failure Dec 29 20:17:00 server-new postfix/smtpd[1560]: [ID 197553 mail.info] lost connection after AUTH from 49.sub-174-252-167.myvzw.com[174.252.167.49] Dec 29 20:17:00 server-new postfix/smtpd[1560]: [ID 197553 mail.info] disconnect from 49.sub-174-252-167.myvzw.com[174.252.167.49] In order to fix these errors, I had to do the following. 5. Created a SASL authentication db with the following command: # /usr/local/sbin/saslpasswd2 -f /etc/sasldb2 -u domain.com user (this step is not listed in the above manual) 6. Very Important!!! Created the smtpd.conf file in /usr/lib/sasl2. Contents of the conf file are as follows: pwcheck_method: saslauthd saslauthd_version: 2 mech_list: PLAIN LOGIN saslauthd_path: /var/run/saslauthd/mux/mux It should be noted that each time I made changes during trouble-shooting, I restarted postfix. Several times there were missing libraries that it complained about that I had to link or copy over. Also, I had to create a rc script for starting the sasl daemon. I apologize for the lack of technical detail. If anyone has specific questions on how I got this to work please email me at m...@lancertech.com and I will do my best to answer. Respectfully; Mark K. --
RE: Relay restrictions
With Noel's explanation I think I got it figured out, but before I try it I'd appreciate other brains validating what I've created as a sanity check. Here's what I have: snip from main.cf ### smtpd_recipient_restrictions = # Check what hosts are allowed to relay. Anything not # listed in the access table is discarded. check_client_access hash:/etc/postfix/client_access # See what addresses are allowed to relay as senders. # Check them against allowed recipients in recipient_access # under smtpd_restriction_classes. check_sender_access hash:/etc/postfix/sender_access check_client_access static:discard reject_unauth_destination ### smtpd_restriction_classes = authorized_recipients authorized_recipients = check_recipient_access hash:/etc/postfix/recipient_access, discard ### /snip from main.cf sender_access send...@wf.com authorized_recipients send...@wf.com authorized_recipients send...@wf.com authorized_recipients send...@wf.com authorized_recipients send...@wf.com authorized_recipients send...@wf.com authorized_recipients /sender_access recipient_access send...@wf.com OK send...@wf.com OK recipie...@wf.com OK recipie...@wf.com OK recipie...@wf.com OK recipie...@wf.com OK /recipient_access So if I did this right, any host listed in client_access will be able to relay from anyone, to anyone (I'm actually thinking I want to change that, but first things first). Any address listed in sender_access can relay, but only to the recipients listed in recipient_access. Mail sent to recipients not allowed under smtpd_restriction_classes is discarded (vs. rejected). Is this setup correct for that? Thanks in advance. Thanks for the help, Noel and all. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: Wednesday, December 29, 2010 11:28 AM To: postfix-users@postfix.org Subject: Re: Relay restrictions On 12/29/2010 10:31 AM, michael.lar...@wellsfargo.com wrote: Back in August several people helped me with the problem linked here: _http://www.mail-archive.com/postfix-users@postfix.org/msg26629.html_ It was almost what I needed, but I didn't completely understand what I was asking for at the time, and the configuration is causing problems. I need to implement some further restrictions and can't figure out how to do it. The current restrictions in my main.cf look like this: smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_access check_sender_access hash:/etc/postfix/sender_access check_recipient_access hash:/etc/postfix/recipient_access check_client_access static:discard reject_unauth_destination An unintended consequence is that any address that is allowed as a sender is allowed to relay to anyone, even invalid addresses. I need to be able to specify a very small subset of valid addresses as recipients, based on who the sender is, and discard all the others. Since this setup is first-match-wins, the relay doesn't evaluate anything past check_sender_access. I need it to evaluate sender, and if the sender is allowed, discard any recipient address that isn't explicitly allowed. I tried blacklisting the addresses I knew to, and that worked, but new and/or invalid addresses keep turning up in the test code, and the blacklist has become unmanageable. I need a way to implement check_sender_access_AND_check_recipient_access. I assume Noel anticipated that need when he talked about using smtpd_restriction_classes for multiple-factor tests, but reading the documentation didn't shed any light on how to implement in this situation. Can anyone help turn back the darkness? Read this several times until it starts to make sense: http://www.postfix.org/RESTRICTION_CLASS_README.html Postfix restriction classes allow you to nest restrictions so that you can combine sender and recipient tests. This will work for you if your list of allowed senders can send to any of the allowed recipients. The example http://www.postfix.org/RESTRICTION_CLASS_README.html#external does just about exactly what you ask for, just use full recipient addresses instead of domains for the local_domains list (you can use a different name than local_domains in your setup). If you need finer control - ie. each sender has their own list of allowed recipients, you'll need to use an external policy service to make those decisions. This is quite a bit more complex than restriction classes, but gives you much finer control over postfix decisions. http://www.postfix.org/SMTPD_POLICY_README.html Here are some pre-built policy servers; maybe one of them would help if you need fine-grained control. http://www.postfix.org/addon.html#policy -- Noel Jones
Re: Postfix and Myvzw.com POP3 email
On Thu, Dec 30, 2010 at 06:22:16AM -0500, Mark Khan wrote: 4. Downloaded the latest version (2.7.2) of postfix. In compiling v2.7.2, it is extremely important to pass the correct arguments to your compiler. I used the following commands for Solaris 10: # make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL-I/usr/include/sasl -I/usr/local/include/sasl -I/usr/local/lib/sasl2 AUXLIBS=-L/usr/local/lib -lsasl2 For a submission service, it is best-practice to also support TLS. If I recall correctly, from the ldd output you posted previously, your original Postfix binaries had support for TLS (and also LDAP, ... but you likely don't need that). -- Viktor.
Re: Relay restrictions
On Thu, Dec 30, 2010 at 09:15:30AM -0600, michael.lar...@wellsfargo.com wrote: With Noel's explanation I think I got it figured out, but before I try it I'd appreciate other brains validating what I've created as a sanity check. Here's what I have: snip from main.cf ### smtpd_recipient_restrictions = # Check what hosts are allowed to relay. Anything not # listed in the access table is discarded. check_client_access hash:/etc/postfix/client_access This is not how it works, anything not listed is tested against the rules below. # See what addresses are allowed to relay as senders. # Check them against allowed recipients in recipient_access # under smtpd_restriction_classes. check_sender_access hash:/etc/postfix/sender_access This makes you an open relay for forged sender addresses. check_client_access static:discard After the open-relay, mail from unlisted clients is discarded, why not reject first? reject_unauth_destination DO NOT apply ANY sender checks until you've first applied reject_unauth_destination -- Viktor.
RE: Relay restrictions
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Victor Duchovni Sent: Thursday, December 30, 2010 10:37 AM To: Larsen, Michael W. Cc: postfix-users@postfix.org Subject: Re: Relay restrictions On Thu, Dec 30, 2010 at 09:15:30AM -0600, michael.lar...@wellsfargo.com wrote: With Noel's explanation I think I got it figured out, but before I try it I'd appreciate other brains validating what I've created as a sanity check. Here's what I have: snip from main.cf ### smtpd_recipient_restrictions = # Check what hosts are allowed to relay. Anything not # listed in the access table is discarded. check_client_access hash:/etc/postfix/client_access Viktor said: This is not how it works, anything not listed is tested against the rules below. Actually, the comments were just me being confused. The original intent was to allow relay of all mail from/to the hosts listed in the access table, and all other hosts be evaluated against the subsequent rules. # See what addresses are allowed to relay as senders. # Check them against allowed recipients in recipient_access # under smtpd_restriction_classes. check_sender_access hash:/etc/postfix/sender_access Viktor said: This makes you an open relay for forged sender addresses. Yes, Noel made me aware of that risk when answering the original query, I just don't know what to do about it and maintain the basic functionality of what I'm trying to achieve (see below). check_client_access static:discard Viktor said: After the open-relay, mail from unlisted clients is discarded, why not reject first? Because we don't want reject messages going back to the application. We just want unwanted mail to disappear. reject_unauth_destination Viktor said: DO NOT apply ANY sender checks until you've first applied reject_unauth_destination This goes back to one of the original problems I was trying to solve: The problem I'm having is with reject_unauth_destination. If I specify the corporate domain name in relay.db, any email address with that domain name relays, which is exactly the opposite of what I want. _Without_ the corporate domain name in relay.db, everything is rejected before whitelist/blacklist are checked. I want to relay only the from hosts/to email addresses specified in the whitelist, and DISCARD everything else. Is this possible? Noel replied with: Move reject_unauth_destination to below your white/black lists. Once you do that, you're on your own to insure you don't create an open relay, but your access maps give you full control over who is allowed to relay. -- Viktor.
Re: Relay restrictions
On Thu, Dec 30, 2010 at 12:17:57PM -0600, michael.lar...@wellsfargo.com wrote:
# See what addresses are allowed to relay as senders.
# Check them against allowed recipients in recipient_access
# under smtpd_restriction_classes.
check_sender_access hash:/etc/postfix/sender_access
Viktor said:
This makes you an open relay for forged sender addresses.
Yes, Noel made me aware of that risk when answering the original query, I
just don't know what to do about it and maintain the basic functionality of
what I'm trying to achieve (see below).
Not *a risk*, rather an inevitable, and difficult to recover from exploit.
DO NOT base relay access on envelope sender address information, it is
trivially forged.
Upthread:
I need a way to implement
check_sender_access_AND_check_recipient_access
Your problem is almost certainly best solved by using each of the
multiple restriction lists to check each of the required conditions.
cidr = cidr:${config_directory}/
indexed = ${default_database_type}:${config_directory}/
smtpd_client_restrictions =
check_client_access ${cidr}allowed-clients,
check_client_access static:discard
smtpd_sender_restrictions =
check_sender_access ${indexed}allowed-senders,
check_client_access static:discard
# The default is likely fine:
smtpd_recipient_restrictions =
check_recipient_access ${indexed}allowed-recipients,
check_client_access static:discard,
#
# At least one reject by default rule is required in
# smtpd_recipient_restrictions, defeat the logic by
# listing permit, then reject. In reality permit = discard.
#
permit, reject
With this all mail is discarded unless all the conditions below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup table)
--
Viktor.
RE: Relay restrictions
Thanks for trying to help Viktor, but I don't think this configuration will
work for me. Let me try to explain; when I made my original post, others on the
list were somewhat surprised regarding my intent.
This relay isn't so much a relay as a choke point. The test network I support
is subject to tight quotas regarding traffic on the corporate email system. I
need all mail discarded unless it meets the following conditions:
All mail relays for hosts listed in client_access
Mail from hosts not listed in client_access is subject
to sender/recipient restrictions
If a sender is allowed (rare), recipients are evaluated,
and either relayed (even rarer) or discarded
-Original Message-
From: Victor Duchovni [mailto:victor.ducho...@morganstanley.com]
Sent: Thursday, December 30, 2010 12:45 PM
To: Larsen, Michael W.
Cc: postfix-users@postfix.org
Subject: Re: Relay restrictions
On Thu, Dec 30, 2010 at 12:17:57PM -0600, michael.lar...@wellsfargo.com wrote:
# See what addresses are allowed to relay as senders.
# Check them against allowed recipients in recipient_access
# under smtpd_restriction_classes.
check_sender_access hash:/etc/postfix/sender_access
Viktor said:
This makes you an open relay for forged sender addresses.
Yes, Noel made me aware of that risk when answering the original query, I
just don't know what to do about it and maintain the basic functionality of
what I'm trying to achieve (see below).
Not *a risk*, rather an inevitable, and difficult to recover from exploit.
DO NOT base relay access on envelope sender address information, it is
trivially forged.
Upthread:
I need a way to implement
check_sender_access_AND_check_recipient_access
Your problem is almost certainly best solved by using each of the
multiple restriction lists to check each of the required conditions.
cidr = cidr:${config_directory}/
indexed = ${default_database_type}:${config_directory}/
smtpd_client_restrictions =
check_client_access ${cidr}allowed-clients,
check_client_access static:discard
smtpd_sender_restrictions =
check_sender_access ${indexed}allowed-senders,
check_client_access static:discard
# The default is likely fine:
smtpd_recipient_restrictions =
check_recipient_access ${indexed}allowed-recipients,
check_client_access static:discard,
#
# At least one reject by default rule is required in
# smtpd_recipient_restrictions, defeat the logic by
# listing permit, then reject. In reality permit = discard.
#
permit, reject
With this all mail is discarded unless all the conditions below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup table)
--
Viktor.
Re: postfix client sends partial username/password to server
As Wietse pointed out my network capture program only captures the headers of the tcp packets. That made me draw the wrong conclusion about the partial username. I will start a new threat about this. Hint: if you capture with tcpdump use the -s 0 option to capture the full tcp packages
with sasl authentication the username in sent twice
I want to relay my mail from a Trixbox (Centos 5.5) pbx to my password protected smtp server. The problem is that acces from the trixbox is always denied, because Postfix tries to login with username:username:password I installed Postfix on an Ubuntu distro, and here the relaying works. Postfix logs in with username:password I copied the main.cf from Ubuntu to Trixbox (recompiled sasl_password.db en restarted postfix) and the Trixbox still tries to login with username:username:password and access is denied. Does anybody has an idea how I can get the login right? Rob
Re: Relay restrictions
On Thu, Dec 30, 2010 at 01:45:57PM -0600, michael.lar...@wellsfargo.com wrote:
Thanks for trying to help Viktor, but I don't think this configuration will
work for me. Let me try to explain; when I made my original post, others on
the list were somewhat surprised regarding my intent.
This relay isn't so much a relay as a choke point. The test network I support
is subject to tight quotas regarding traffic on the corporate email system. I
need all mail discarded unless it meets the following conditions:
All mail relays for hosts listed in client_access
Best enforced in smtpd_client_restrictions.
Mail from hosts not listed in client_access is subject
to sender/recipient restrictions
Best enforced via suitable and separate smtpd_sender_restrictions
and smtpd_recipient_restrictions.
If a sender is allowed (rare), recipients are evaluated,
and either relayed (even rarer) or discarded
That's exactly what the configuration I posted does. What about
the configuration below fails to meet your requirements?
Your problem is almost certainly best solved by using each of the
multiple restriction lists to check each of the required conditions.
cidr = cidr:${config_directory}/
indexed = ${default_database_type}:${config_directory}/
smtpd_client_restrictions =
check_client_access ${cidr}allowed-clients,
check_client_access static:discard
smtpd_sender_restrictions =
check_sender_access ${indexed}allowed-senders,
check_client_access static:discard
smtpd_recipient_restrictions =
check_recipient_access ${indexed}allowed-recipients,
check_client_access static:discard,
#
# At least one reject by default rule is required in
# smtpd_recipient_restrictions, defeat the logic by
# listing permit, then reject. In reality permit = discard.
#
permit, reject
With this all mail is discarded unless all the conditions below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup table)
--
Viktor.
Re: with sasl authentication the username in sent twice
On Thu, Dec 30, 2010 at 08:52:59PM +0100, Rob van Dam wrote: I want to relay my mail from a Trixbox (Centos 5.5) pbx to my password protected smtp server. The problem is that acces from the trixbox is always denied, because Postfix tries to login with username:username:password I installed Postfix on an Ubuntu distro, and here the relaying works. Postfix logs in with username:password http://www.postfix.org/postconf.5.html#send_cyrus_sasl_authzid -- Viktor.
RE: Relay restrictions
Perhaps I misunderstood, but you said:
With this all mail is discarded unless *all* (my emphasis) the conditions
below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup
table)
Which isn't what I want. For hosts in client_access, I don't want any
sender/recipient evaluation - I just want it to flow through - all of it. For
hosts not in client_access, I want it assumed they're allowed, but the
sender/recipient restrictions asserted.
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of Victor Duchovni
Sent: Thursday, December 30, 2010 1:55 PM
To: postfix-users@postfix.org
Subject: Re: Relay restrictions
On Thu, Dec 30, 2010 at 01:45:57PM -0600, michael.lar...@wellsfargo.com wrote:
Thanks for trying to help Viktor, but I don't think this configuration will
work for me. Let me try to explain; when I made my original post, others on
the list were somewhat surprised regarding my intent.
This relay isn't so much a relay as a choke point. The test network I support
is subject to tight quotas regarding traffic on the corporate email system. I
need all mail discarded unless it meets the following conditions:
All mail relays for hosts listed in client_access
Best enforced in smtpd_client_restrictions.
Mail from hosts not listed in client_access is subject
to sender/recipient restrictions
Best enforced via suitable and separate smtpd_sender_restrictions
and smtpd_recipient_restrictions.
If a sender is allowed (rare), recipients are evaluated,
and either relayed (even rarer) or discarded
That's exactly what the configuration I posted does. What about
the configuration below fails to meet your requirements?
Your problem is almost certainly best solved by using each of the
multiple restriction lists to check each of the required conditions.
cidr = cidr:${config_directory}/
indexed = ${default_database_type}:${config_directory}/
smtpd_client_restrictions =
check_client_access ${cidr}allowed-clients,
check_client_access static:discard
smtpd_sender_restrictions =
check_sender_access ${indexed}allowed-senders,
check_client_access static:discard
smtpd_recipient_restrictions =
check_recipient_access ${indexed}allowed-recipients,
check_client_access static:discard,
#
# At least one reject by default rule is required in
# smtpd_recipient_restrictions, defeat the logic by
# listing permit, then reject. In reality permit = discard.
#
permit, reject
With this all mail is discarded unless all the conditions below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup table)
--
Viktor.
Re: with sasl authentication the username in sent twice
On 30-12-10 20:59, Victor Duchovni wrote: http://www.postfix.org/postconf.5.html#send_cyrus_sasl_authzid Thanks for the reply! When I run postconf I can see that send_cyrus_sasl_authzid is set to no in Ubuntu. In Trixbox this option is not set at all. Setting this option in main.cf on Trixbox didn't help unfortunately (i did restart postfix) Rob
Re: with sasl authentication the username in sent twice
Rob van Dam: On 30-12-10 20:59, Victor Duchovni wrote: http://www.postfix.org/postconf.5.html#send_cyrus_sasl_authzid Thanks for the reply! When I run postconf I can see that send_cyrus_sasl_authzid is set to no in Ubuntu. In Trixbox this option is not set at all. Setting this option in main.cf on Trixbox didn't help unfortunately (i did restart postfix) What is the output from postconf mail_version As documented this parameter was introduced with Postfix 2.4.4. Wietse
Re: with sasl authentication the username in sent twice
On 30-12-10 21:17, Rob van Dam wrote: On 30-12-10 20:59, Victor Duchovni wrote: http://www.postfix.org/postconf.5.html#send_cyrus_sasl_authzid Thanks for the reply! When I run postconf I can see that send_cyrus_sasl_authzid is set to no in Ubuntu. In Trixbox this option is not set at all. Setting this option in main.cf on Trixbox didn't help unfortunately (i did restart postfix) Rob Ah the postfix version is too old: [trixbox1.localdomain postfix]# postconf -d | grep mail_version mail_version = 2.3.3 Is there a workaround for the older versions? Rob
Re: Relay restrictions
On Thu, Dec 30, 2010 at 02:09:57PM -0600, michael.lar...@wellsfargo.com wrote:
Perhaps I misunderstood, but you said:
With this all mail is discarded unless *all* (my emphasis) the conditions
below are met:
- From an allowed SMTP client (IP address CIDR table)
- From an allowed envelope sender (indexed via postmap lookup table)
- To an allowed envelope recipient (indexed via postmap lookup
table)
Which isn't what I want. For hosts in client_access, I don't want any
sender/recipient evaluation - I just want it to flow through - all of
it. For hosts not in client_access, I want it assumed they're allowed,
but the sender/recipient restrictions asserted.
In that case change the client restrictions to OR, but keep sender
and recipient as AND.
main.cf:
indexed = ${default_database_type}:${config_directory}/
cidr = cidr:${config_directory}/
smtpd_restriction_classes = discard_all
discard_all = static:discard
smtpd_sender_restrictions =
check_sender_access ${indexed}allowed-senders
check_client_access ${cidr}allowed-clients,
smtpd_recipient_restrictions =
check_recipient_access ${indexed}allowed-recipients,
check_client_access ${cidr}allowed-clients,
#
# Required to appease validation logic, in-practice,
# allowed-clients will perimit all IPs, some to deliver
# and the rest to discard.
#
reject
allowed-clients:
192.0.2.1 permit
0.0.0.0/0 discard_all, permit
--
Viktor.
mail(mailutils) appending full host name instead of domain
Afternoon,
I am trying to setup a null or satellite client on debian system.
The mail cli is appending hostname.domain.com instead of the expected
domain.com.
$ mail user
blah
Sends mail to the local host instead of the domain.
What have I missed.
Thanks
Steve
/etc/mailname
domain.com
/etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate delayed mail warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = domain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = host.domain.com, localhost.domain.com, localhost
relayhost = smtp.domain.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
Re: mail(mailutils) appending full host name instead of domain
On Thu, Dec 30, 2010 at 03:09:07PM -0600, Steve Pribyl wrote: $ mail user blah Sends mail to the local host instead of the domain. What have I missed. http://www.postfix.org/BASIC_CONFIGURATION_README.html#myorigin http://www.postfix.org/MULTI_INSTANCE_README.html#quick -- Viktor.
Re: mail(mailutils) appending full host name instead of domain
Steve Pribyl: Afternoon, I am trying to setup a null or satellite client on debian system. The mail cli is appending hostname.domain.com instead of the expected domain.com. The mail command is not part of Postfix. Wietse
Re: with sasl authentication the username in sent twice
On 30-12-10 21:44, Victor Duchovni wrote: On Thu, Dec 30, 2010 at 09:32:48PM +0100, Rob van Dam wrote: What is the output from postconf mail_version As documented this parameter was introduced with Postfix 2.4.4. Wietse Hello Wietse, I just posted that my Postfix was too old, when I got this mail. I have Postfix version 2.3.3. Is there a workaround for older versions? If you need this feature you need 2.4.4 or later. Hello Viktor, I will look if I can update Postfix on the Trixbox. Seems Centos 5.5 is shipping an old version of Postfix. Thanks for the help. Rob
Re: mail(mailutils) appending full host name instead of domain
On Thu, Dec 30, 2010 at 11:00:17PM +0100, Jeroen Geilman wrote: On 12/30/10 10:09 PM, Steve Pribyl wrote: Afternoon, I am trying to setup a null or satellite client on debian system. Then you can install a null client, such as ssmtp or nullmailer. Much easier to configure than full-blown MTA, with none of the inherent risks. No real risks in installing a Postfix null-client, just more rope whether you need it or not. -- Viktor.
body_checks ... can a header be inserted?
With body checks, is there a way to insert a header or otherwise flag the mail in a way CMUSieve could detect? -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
Phil Howard: With body checks, is there a way to insert a header or otherwise flag the mail in a way CMUSieve could detect? Unlike some software, Postfix behaves as documented, so you can easily establish from the manpage how the prepend action works. Wietse
Re: mail(mailutils) appending full host name instead of domain
On 12/30/10 11:05 PM, Victor Duchovni wrote: On Thu, Dec 30, 2010 at 11:00:17PM +0100, Jeroen Geilman wrote: On 12/30/10 10:09 PM, Steve Pribyl wrote: Afternoon, I am trying to setup a null or satellite client on debian system. Then you can install a null client, such as ssmtp or nullmailer. Much easier to configure than full-blown MTA, with none of the inherent risks. No real risks in installing a Postfix null-client, just more rope whether you need it or not. Of course, I was referring more to the running an MTA that can also receive lots of spam when you don't actually want to receive anything bit. He did start out by saying he wants only to send mail, not receive it. If he has complex requirements that can't be satisfied by a (usually very simple) nullmailer, postfix is a viable choice; I did not mean to imply that it isn't. -- J.
Re: mail(mailutils) appending full host name instead of domain
On Fri, Dec 31, 2010 at 12:55:31AM +0100, Jeroen Geilman wrote: Of course, I was referring more to the running an MTA that can also receive lots of spam when you don't actually want to receive anything bit. A Postfix null-client does not receive any external mail master_service_disable = inet inet_interfaces = 127.0.0.1 He did start out by saying he wants only to send mail, not receive it. That's what Postfix null-clients do. If he has complex requirements that can't be satisfied by a (usually very simple) nullmailer, postfix is a viable choice; I did not mean to imply that it isn't. The extra rope provides reliable queue management, sensible recovery when the remote MTA comes back up, SASL authentication, customizable rewriting of locally generated mail from root, and other system accounts, ... In a large corporate environment, a more capable null-client is handy. For a very small shop, this may not be useful. I would not recommend any locally queueing MTA on a laptop where conserving battery power is a priority, there MUAs such as Thunderbird, that submit directly to a central MSA make more sense. -- Viktor.
Available: preliminary postscreen STARTTLS support
Wietse Venema: I have built an event-driven TLS proxy for postscreen(8). This addresses the problem that postscreen(8) could not be used when SMTP clients require STARTTLS support. The new daemon is called starttlsd(8). When a non-whitelisted (*) SMTP client sends a STARTTLS command, postscreen(8) will hand off the connection to starttlsd(8) and read/write the plaintext to/from starttlsd(8). The challenge was that one starttlsd(8) must be able to handle the TLS = plaintext translation for more than one SMTP client, but thanks to careful planning, it worked out of the box. This is uploaded as postfix-2.8-20101230-nonprod. The code has had limited testing, so keep an eye on things if you intend to expose it to the network. Wietse
