Re: sending email with Gnus
Ralf Hildebrandt: * LuKreme krem...@kreme.com: Postfix does not 'support' TLS at all. I wouldn't say it that way. STARTTLS looks like TLS support, if you ask me It should work with Gnu TLS as well as with any other TLS library. As far as I knwo it doesn't :) A couple years ago, Gnu TLS would exit the program (exit status 2) instead of reporting an error to Postfix, so that Postfix could switch to plaintext where appropriate. http://www.postfix.org/TLS_README.html#build_tls Wietse
Re: sending email with Gnus
* Wietse Venema wie...@porcupine.org: A couple years ago, Gnu TLS would exit the program (exit status 2) instead of reporting an error to Postfix, so that Postfix could switch to plaintext where appropriate. http://www.postfix.org/TLS_README.html#build_tls Should I retry a build with GNUTLS? -- Ralf Hildebrandt (ralf.hildebra...@charite.de) snick...@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
Re: alias question
I'm sorry but i don't get it, if i have this two lines:
local_transport = virtual
virtual_alias_maps = hash:/etc/postfix/alias-virtual
and before i had:
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
and isn't work anyway.
Can anyone give me another direction?
Thanks
On Sat, Feb 28, 2009 at 3:16 PM, mouss mo...@ml.netoyen.net wrote:
Leonardo Coelho a écrit :
Hey guys this is my postconf -n output:
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
inet_interfaces = 127.0.0.1, 10.1.1.107, 189.11.37.1xx
invalid_hostname_reject_code = 450
local_transport = virtual
alias_maps only work in local, not virtual. so move your alias to
virtual_alias_maps.
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 0
mailbox_transport = virtual
maps_rbl_reject_code = 450
message_size_limit = 0
mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
mydestination = mail.domain.com.br http://mail.domain.com.br,
localhost, mail2.domain.com.br http://mail2.domain.com.br
myhostname = mail.domain.com.br http://mail.domain.com.br
mynetworks = 192.168.0.0/24 http://192.168.0.0/24 192.168.x.x/24
192.168.x.x/24 192.168.x.x/24 189.11.37.1xx/32
non_fqdn_reject_code = 450
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/Rox)
smtpd_client_restrictions = permit_mynetworks, reject_non_fqdn_sender,
reject_rbl_client sbl-xbl.spamhaus.org http://sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net http://bl.spamcop.net,
reject_unknown_sender_domain,permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_sender,
reject_unauth_destination,
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = domain.com.br http://domain.com.br
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks,
reject_unknown_sender_domain, reject_non_fqdn_sender, permit
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /etc/ssl/private/postfix.pem
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/alias-virtual
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains =
mysql:/etc/postfix/mysql_virtual_domains_maps.cf
http://mysql_virtual_domains_maps.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
http://mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 5000
virtual_transport = dovecot
virtual_uid_maps = static:5000
and log non-verbose:
mail2 postfix/smtpd[3642]: 901AB5FAFD2: client=rv-out-0708.google.com
http://rv-out-0708.google.com[209.85.198.245]
mail2 postfix/cleanup[3023]: 901AB5FAFD2:
message-id=39f8772a0902270313v7e620027q330920899717e...@mail.gmail.com
mailto:39f8772a0902270313v7e620027q330920899717e...@mail.gmail.com
mail2 postfix/qmgr[31327]: 901AB5FAFD2: from=leonardoscoe...@gmail.com
mailto:leonardoscoe...@gmail.com, size=2430, nrcpt=1 (queue active)
mail2 postfix/pipe[4168]: 901AB5FAFD2: to=supo...@eletricadw.com.br
mailto:supo...@eletricadw.com.br, relay=dovecot, delay=1,
delays=0.98/0/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot
service)
mail2 postfix/qmgr[31327]: 901AB5FAFD2: removed
--
First they ignore you, then they laugh at you, then they fight you, then
you win. - Mahatma Gandhi
Linux User #373408
cabelohw.blogspot.com
GPGkey ID 8AEEAAEB -- http://pgp.mit.edu
Re: sending email with Gnus
Ralf Hildebrandt: * Wietse Venema wie...@porcupine.org: A couple years ago, Gnu TLS would exit the program (exit status 2) instead of reporting an error to Postfix, so that Postfix could switch to plaintext where appropriate. http://www.postfix.org/TLS_README.html#build_tls Should I retry a build with GNUTLS? Apparently this library freaks out when there's no /dev/*random, so this is a double idiot problem. Idiot #1: GnuTLS library calls exit instead of allowing applications such as Postfix to provide randomness. Postfix provides randomness via a tlsmgr daemon that runs outside the chroot jail and that has access to /dev/*random. Idiot #2: Linux distro turns on CHROOT by default, but provides no /dev/*random. You're welcome to reproduce this. Wietse
Prioritising outgoing mail
Hi list, From me a question that seems to be asked now and then here, but I could not find any answers even on whether this is possible in the first place. I would like to be able to prioritise outgoing e-mail so they do not get stuck in the queue. This as I now and then send out a large number of e-mails with attachments, and that saturates my connection for a prolonged time. It doesn't matter that those mails get out slower, as long as they get out eventually I'm happy. However it can clog up other e-mails that I do want to get tackled first. Any way to do this? Any solution will do as long as it can run on a single server, and an upgrade of my uplink is also not an option (financially, and it is too infrequent to require more bandwidth but frequent enough to irritate me that my other e-mails do not get out quickly). Separate mailqueues, whatever: just a way to get normal priority mails first in line. Thanks. Wouter.
Re: outbound email destination based on sender's domain
Hi again, Still working on this - something that I didn't mention (sorry, should have) was that the Postfix gateway is multi-homed and that the other edge Postfix systems (and the internal mail servers) are each on different subnets. Example: a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1 b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1 c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1 ...and so on. The gateway system has a NIC for each pair of systems and the traffic is forwarded through a router from the internal server to the gateway and then either back to one of the other internal servers or out to the edge proxy that matches the sender's domain from the internal mail server. How does this new info affect the previous solution that you provided? Thanks... On Fri, Feb 27, 2009 at 6:50 PM, Iad Scoot iad.sc...@gmail.com wrote: Gotcha - and after a little more research I've found a couple of examples online. It'll be Monday before I can try but much thanks again - I will post back my outcome. - iad On Fri, Feb 27, 2009 at 6:33 PM, Barney Desmond barneydesm...@gmail.com wrote: 2009/2/28 Iad Scoot iad.sc...@gmail.com: Hey thanks for the info - it looks like (from what I've read so far) that the sender_dependent_relayhost_maps parameter is for specific users - is there any way to do this for any user (or all users) in a given domain w/o having to list their full address in the map file? That should work; according to the documentation, The tables are searched by the envelope sender address and @domain. I admit I haven't *actually* used this myself, but I'm guessing you either use senderdomain.com (like a transport table) or @senderdomain.com (virtual-style catchall) as the key to the lookup. Testing will tell you in a matter of minutes.
Re: Prioritising outgoing mail
On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote: Hi list, From me a question that seems to be asked now and then here, but I could not find any answers even on whether this is possible in the first place. I would like to be able to prioritise outgoing e-mail so they do not get stuck in the queue. This as I now and then send out a large number of e-mails with attachments, and that saturates my connection for a prolonged time. It doesn't matter that those mails get out slower, as long as they get out eventually I'm happy. Use a custom transport for these messages with a low concurrency limit, or use traffic shaping in the TCP stack to limit the bandwidth per SMTP connection. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Prioritising outgoing mail
On 2 Mar 09, at 23:09, Victor Duchovni wrote: On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote: Hi list, From me a question that seems to be asked now and then here, but I could not find any answers even on whether this is possible in the first place. I would like to be able to prioritise outgoing e-mail so they do not get stuck in the queue. This as I now and then send out a large number of e-mails with attachments, and that saturates my connection for a prolonged time. It doesn't matter that those mails get out slower, as long as they get out eventually I'm happy. Use a custom transport for these messages with a low concurrency limit, You mean like installing sendmail or so in parallel to postfix and then have sendmail send out the lower-priority mails? or use traffic shaping in the TCP stack to limit the bandwidth per SMTP connection. And how would that get certain mails out with priority? It sounds to me like this would slow down the overall process. I have up to 100 smtp processes running at a time, but as long as new mails end up at the back of the queue still no progress there. They have to come first. Wouter. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Prioritising outgoing mail
Wouter van Marle: On 2 Mar 09, at 23:09, Victor Duchovni wrote: On Mon, Mar 02, 2009 at 10:44:21PM +0800, Wouter van Marle wrote: Hi list, From me a question that seems to be asked now and then here, but I could not find any answers even on whether this is possible in the first place. I would like to be able to prioritise outgoing e-mail so they do not get stuck in the queue. This as I now and then send out a large number of e-mails with attachments, and that saturates my connection for a prolonged time. It doesn't matter that those mails get out slower, as long as they get out eventually I'm happy. Use a custom transport for these messages with a low concurrency limit, You mean like installing sendmail or so in parallel to postfix and then have sendmail send out the lower-priority mails? No, use a POSTFIX transport map. or use traffic shaping in the TCP stack to limit the bandwidth per SMTP connection. And how would that get certain mails out with priority? It sounds to me With the concurrency limit (see above), low priority mail can use up only a limited portion of the bandwidth. Wietse
Re: alias question
Massive confusion, and looking back on the thread somewhat, I still
think we're lacking a good description of the problem.
On Mon March 2 2009 06:31:09 Leonardo Coelho wrote:
I'm sorry but i don't get it, if i have this two lines:
local_transport = virtual
Don't do this. It probably doesn't work anyway. We have address classes
with proper *_transport defaults. The local_transport is of course
local(8), which is designed to work with Unix users and traditional
Unix system aliases(5).
Where did you get this idea? It's a bad idea. See the
ADDRESS_CLASS_README to begin to understand how different classes are
handled in Postfix ... the right way.
virtual_alias_maps = hash:/etc/postfix/alias-virtual
See the VIRTUAL_README and aforementioned ADDRESS_CLASS_README to get
the difference between virtual(8) mailboxes and virtual(5) aliases.
Also, be aware that virtual_alias_maps apply to ALL mail, not just the
domains defined in virtual_alias_domains.
and before i had:
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
and isn't work anyway.
MYSQL_README tells you how to construct a proper query, but it assumes
you're already up to speed on mysql. A hash: map is the way to start
out, then when that works, all you have to do is import the data into
your relational database.
I suggest, as does DATABASE_README, that you figure out the Postfix
workings before you muddy it all up with mysql confusion.
Can anyone give me another direction?
Read the documentation? Well, I'll look at your config and logs below.
On Sat, Feb 28, 2009 at 3:16 PM, mouss mo...@ml.netoyen.net wrote:
Leonardo Coelho a écrit :
Hey guys this is my postconf -n output:
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
inet_interfaces = 127.0.0.1, 10.1.1.107, 189.11.37.1xx
invalid_hostname_reject_code = 450
local_transport = virtual
alias_maps only work in local, not virtual. so move your alias
to virtual_alias_maps.
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 0
mailbox_transport = virtual
maps_rbl_reject_code = 450
This was deprecated YEARS ago. You must have followed a HOWTO which is
outdated in addition to being just plain bad.
message_size_limit = 0
mime_header_checks =
regexp:/etc/postfix/mime_header_checks.regexp mydestination =
mail.domain.com.br http://mail.domain.com.br, localhost,
mail2.domain.com.br http://mail2.domain.com.br myhostname =
mail.domain.com.br http://mail.domain.com.br mynetworks =
192.168.0.0/24 http://192.168.0.0/24 192.168.x.x/24
192.168.x.x/24 192.168.x.x/24 189.11.37.1xx/32
non_fqdn_reject_code = 450
receive_override_options = no_address_mappings
See postconf.5.html#receive_override_options to understand what this
does. Don't use settings that you don't understand. Looks like that
describes a big part of your configuration.
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database =
btree:${queue_directory}/smtp_scache smtpd_banner = $myhostname
ESMTP $mail_name (Debian/Rox)
smtpd_client_restrictions =
permit_mynetworks, reject_non_fqdn_sender, reject_rbl_client
sbl-xbl.spamhaus.org http://sbl-xbl.spamhaus.org,
(Please do NOT post in HTML on a mailing list, thank you.)
reject_rbl_client bl.spamcop.net http://bl.spamcop.net,
reject_unknown_sender_domain,permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_sender,
reject_unauth_destination,
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = domain.com.br http://domain.com.br
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks,
reject_unknown_sender_domain, reject_non_fqdn_sender, permit
Three different smtpd(8) restriction stages, no good reason for them
(such as a whitelisting restriction which might be unsafe in
smtpd_recipient_restrictions.) I would suggest consolidation of these
into smtpd_recipient_restrictions, making it easier to follow and to
maintain.
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /etc/ssl/private/postfix.pem
smtpd_tls_session_cache_database =
btree:${queue_directory}/smtpd_scache smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
Why are you using transport_maps ?
virtual_alias_maps = hash:/etc/postfix/alias-virtual
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains =
mysql:/etc/postfix/mysql_virtual_domains_maps.cf
http://mysql_virtual_domains_maps.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps =
mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
http://mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 5000
virtual_transport =
Re: mysql lookup errors
On Mon March 2 2009 12:51:23 kj wrote: I'm seeing this in the logs: Mar 2 18:18:05 web postfix/cleanup[27207]: warning: mysql query failed: MySQL server has gone away snip Mar 2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 from=apache snip RHEL5, with the stock Red Hat rpm recompiled with mysql support. That RPM is probably chroot'ed by the distributor. My first guess is that you're seeing a chroot problem. My second guess, SELinux. In either case, seek support from your vendor for these problems. 1. What could possibly cause postfix to have lookup problems when nothing else does? The server did run out of disc space a few days ago. I did a postsuper -s -v which didn't show any problems. Could the disc space issue have damaged something? 2. Is there a way to enable debugging output for connections from apache? Uh, connections from apache, what? Is that a Postfix question? If so see postconf.5.html#debug_peer_list and list the IP address of the client. See also DEBUG_README (which will also describe the chroot issue and how to get out of it.) However, the logging in your post did not show any connections from apache, it showed submission via sendmail(1) by your apache user. Try man sendmail or sendmail.1.html. 3. I looks like the query fails when the mysql connection has timed out. Can postfix be told to reconnect automatically instead of accepting it as a failure? -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: alias question
On Mon March 2 2009 13:07:18 Victor Duchovni wrote: On Mon, Mar 02, 2009 at 12:56:33PM -0600, /dev/rob0 wrote: Massive confusion, and looking back on the thread somewhat, I still think we're lacking a good description of the problem. On Mon March 2 2009 06:31:09 Leonardo Coelho wrote: I'm sorry but i don't get it, if i have this two lines: local_transport = virtual Don't do this. It probably doesn't work anyway. We have address classes with proper *_transport defaults. The local_transport is of course local(8), which is designed to work with Unix users and traditional Unix system aliases(5). There is nothing wrong with local_transport = virtual, if one wants virtual delivery with no aliases(5) processing or .forward processing for all local users, but often setting mailbox_transport is a better way to handle local (system-user) mail. Thanks. I was thinking, as well, that the someone with such a need might do better using relay_domains and set relay_transport = dovecot, for the domains defined in his virtual_mailbox_domains, since later on the OP also changed virtual_transport. Then the mydestination domains could be moved to virtual_mailbox_domains and mydestination unset. This fits in with the principle of doing the least possible pounding of square pegs into round holes. Of course this is all academic; I doubt the OP really knows what he needs. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: mysql lookup errors
kj a écrit : Hi guys, I'm seeing this in the logs: Mar 2 18:18:05 web postfix/cleanup[27207]: warning: mysql query failed: MySQL server has gone away Mar 2 18:18:05 web postfix/cleanup[27207]: warning: D1D1A71029C: virtual_alias_maps map lookup problem for donny_bra...@example.co.uk Mar 2 18:18:28 web postfix/smtpd[27153]: connect from unknown[xxx.xxx.xxx.xxx] Mar 2 18:18:29 web postfix/trivial-rewrite[27154]: warning: mysql query failed: MySQL server has gone away Mar 2 18:18:29 web postfix/trivial-rewrite[27154]: fatal: mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem Mar 2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 from=apache Mar 2 18:18:30 web postfix/smtpd[27153]: warning: premature end-of-input on private/rewrite socket while reading input attribute name Mar 2 18:18:30 web postfix/smtpd[27153]: warning: problem talking to service rewrite: Success Mar 2 18:18:30 web postfix/cleanup[27207]: warning: premature end-of-input on private/rewrite socket while reading input attribute name Mar 2 18:18:30 web postfix/cleanup[27207]: warning: problem talking to service rewrite: Connection reset by peer Mar 2 18:18:30 web postfix/master[21481]: warning: process /usr/libexec/postfix/trivial-rewrite pid 27154 exit status 1 Mar 2 18:18:31 web postfix/cleanup[27207]: E381E7102B3: message-id=kfw5i5.rhs...@web.example.com Mar 2 18:18:31 web postfix/cleanup[27207]: warning: E381E7102B3: virtual_alias_maps map lookup problem for donny_bra...@example.co.uk Mar 2 18:18:32 web postfix/smtpd[27153]: warning: mysql query failed: MySQL server has gone away Mar 2 18:18:32 web postfix/smtpd[27153]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 451 4.3.0 sa...@some_domain.com: Temporary lookup failure; [snip] replace mysql: with proxy:mysql: and try again.
Restrict external hosts
I have a setup which we use an external mail filtering service and need to limit/restrict external client access. Meaning the MX for the domain points to the filtering service and they relay checked email. I need to limit access to just these network blocks but also allow sasl authenticated as well as the internal network. I also do not want to blindly trust this service so i would like to check the IP address as well as ensuring the recipient is for my domain. can someone point me to an example or man page. I cannot seem to find anything related to limiting inbound smtp clients/servers. Vernon
Re: outbound email destination based on sender's domain
2009/3/3 Iad Scoot iad.sc...@gmail.com: Still working on this - something that I didn't mention (sorry, should have) was that the Postfix gateway is multi-homed and that the other edge Postfix systems (and the internal mail servers) are each on different subnets. Example: a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1 b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1 c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1 ...and so on. The gateway system has a NIC for each pair of systems and the traffic is forwarded through a router from the internal server to the gateway and then either back to one of the other internal servers or out to the edge proxy that matches the sender's domain from the internal mail server. How does this new info affect the previous solution that you provided? Assuming your setup is generally sane, this shouldn't cause you any grief. You *can* bind the postfix smtp client to a given src address, but that's only useful when you're single-homed and want to use one particular address of many (for policy/firewall/whatever reasons). This doesn't apply to you, so that's fine. Another thing people sometimes want is (the currently non-existent) sender-dependent src-address. This is usually because they're trying to optimise their mass-mailings of questionable legitimacy. This also doesn't apply to you, which is fine. Left to its own devices, Postfix will let the network stack figure out how to get the packets to the destination properly. As long as your routing is all working, the details you've provided won't change anything (as far as I know).
Re: Restrict external hosts
Vernon A. Fort wrote: I have a setup which we use an external mail filtering service and need to limit/restrict external client access. Meaning the MX for the domain points to the filtering service and they relay checked email. I need to limit access to just these network blocks but also allow sasl authenticated as well as the internal network. I also do not want to blindly trust this service so i would like to check the IP address as well as ensuring the recipient is for my domain. can someone point me to an example or man page. I cannot seem to find anything related to limiting inbound smtp clients/servers. Vernon Minimal config: # main.cf # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access cidr:/etc/postfix/filter_service reject # filter_service 192.1.0.0/24 OK ... other cidr ranges filter service uses ... -- Noel Jones
Re: Restrict external hosts
Noel Jones wrote: Vernon A. Fort wrote: I have a setup which we use an external mail filtering service and need to limit/restrict external client access. Meaning the MX for the domain points to the filtering service and they relay checked email. I need to limit access to just these network blocks but also allow sasl authenticated as well as the internal network. I also do not want to blindly trust this service so i would like to check the IP address as well as ensuring the recipient is for my domain. can someone point me to an example or man page. I cannot seem to find anything related to limiting inbound smtp clients/servers. Vernon Minimal config: # main.cf # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access cidr:/etc/postfix/filter_service reject # filter_service 192.1.0.0/24 OK ... other cidr ranges filter service uses ... -- Noel Jones Hey Noel, What i have now under the smtpd_*_restrictions: smtpd_sender_restrictions = smtpd_client_restrictions = smtpd_etrn_restrictions = reject smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_helo_access . check_sender_access ... check_client_access (for white listing client sites - just in case they get rbl listed) reject_rbl_client permit smtpd_data_restrictions = reject_unauth_pipelining, permit What i 'thinking' of is: smtpd_sender_restrictions = smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access cidr:/etc/postfix/filter_service.cidr, reject The filter_service.cidr would look like 1.2.3.4/29 OK 1.2.4.4/29 OK 0.0.0.0/0REJECT Would it be redundant to have the permit_sasl and permit_mynetworks under both the smtpd_client and smtpd_recipient? Vernon
RE: mysql lookup errors
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of /dev/rob0 Sent: Tuesday, 3 March 2009 7:31 AM To: postfix-users@postfix.org Subject: Re: mysql lookup errors On Mon March 2 2009 12:51:23 kj wrote: I'm seeing this in the logs: Mar 2 18:18:05 web postfix/cleanup[27207]: warning: mysql query failed: MySQL server has gone away snip Mar 2 18:18:30 web postfix/pickup[26468]: E381E7102B3: uid=48 from=apache snip RHEL5, with the stock Red Hat rpm recompiled with mysql support. That RPM is probably chroot'ed by the distributor. My first guess is that you're seeing a chroot problem. My second guess, SELinux. In either case, seek support from your vendor for these problems. RedHat does not have Postfix chrooting enabled in the distro by default - it seems to be more the Debian-based distros that have that problem. Also, I've never had any problems with SELinux and Postfix in stock RH installs (although I haven't used it with MySql)
Re: Restrict external hosts
Vernon A. Fort wrote: Noel Jones wrote: Vernon A. Fort wrote: I have a setup which we use an external mail filtering service and need to limit/restrict external client access. Meaning the MX for the domain points to the filtering service and they relay checked email. I need to limit access to just these network blocks but also allow sasl authenticated as well as the internal network. I also do not want to blindly trust this service so i would like to check the IP address as well as ensuring the recipient is for my domain. can someone point me to an example or man page. I cannot seem to find anything related to limiting inbound smtp clients/servers. Vernon Minimal config: # main.cf # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access cidr:/etc/postfix/filter_service reject # filter_service 192.1.0.0/24 OK ... other cidr ranges filter service uses ... -- Noel Jones Hey Noel, What i have now under the smtpd_*_restrictions: smtpd_sender_restrictions = smtpd_client_restrictions = smtpd_etrn_restrictions = reject smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_helo_access . check_sender_access ... check_client_access (for white listing client sites - just in case they get rbl listed) reject_rbl_client permit smtpd_data_restrictions = reject_unauth_pipelining, permit What i 'thinking' of is: smtpd_sender_restrictions = smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access cidr:/etc/postfix/filter_service.cidr, reject The filter_service.cidr would look like 1.2.3.4/29 OK 1.2.4.4/29 OK 0.0.0.0/0REJECT Would it be redundant to have the permit_sasl and permit_mynetworks under both the smtpd_client and smtpd_recipient? Vernon You (usually) need permit_sasl_authenticated and permit_mynetworks under each smtpd_*_restrictions in use to exempt trustworthy clients from those checks. If you use a whitelist you will likely need to duplicate that under each section too. That's one reason it's often easier to put everything under smtpd_recipient_restrictions. To add additional restrictions, refer to the example I provided earlier: # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination ... other restrictions here ... check_client_access cidr:/etc/postfix/filter_service reject Important Note: the various check_client_access, reject_rbl_client, various helo checks, and reject_unauth_pipelining restrictions will see the filter service connection info - not the original sender - so they are quite limited in usefulness to you. You could use reject_rhsbl_sender to reject bad sender domains if you can find a service that you consider trustworthy enough for rejections. -- Noel Jones
Re: Restrict external hosts
Noel Jones wrote: Vernon A. Fort wrote: Noel Jones wrote: Vernon A. Fort wrote: I have a setup which we use an external mail filtering service and need to limit/restrict external client access. Meaning the MX for the domain points to the filtering service and they relay checked email. I need to limit access to just these network blocks but also allow sasl authenticated as well as the internal network. I also do not want to blindly trust this service so i would like to check the IP address as well as ensuring the recipient is for my domain. can someone point me to an example or man page. I cannot seem to find anything related to limiting inbound smtp clients/servers. Vernon Minimal config: # main.cf # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access cidr:/etc/postfix/filter_service reject # filter_service 192.1.0.0/24 OK ... other cidr ranges filter service uses ... -- Noel Jones Hey Noel, What i have now under the smtpd_*_restrictions: smtpd_sender_restrictions = smtpd_client_restrictions = smtpd_etrn_restrictions = reject smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_helo_access . check_sender_access ... check_client_access (for white listing client sites - just in case they get rbl listed) reject_rbl_client permit smtpd_data_restrictions = reject_unauth_pipelining, permit What i 'thinking' of is: smtpd_sender_restrictions = smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access cidr:/etc/postfix/filter_service.cidr, reject The filter_service.cidr would look like 1.2.3.4/29 OK 1.2.4.4/29 OK 0.0.0.0/0REJECT Would it be redundant to have the permit_sasl and permit_mynetworks under both the smtpd_client and smtpd_recipient? Vernon You (usually) need permit_sasl_authenticated and permit_mynetworks under each smtpd_*_restrictions in use to exempt trustworthy clients from those checks. If you use a whitelist you will likely need to duplicate that under each section too. That's one reason it's often easier to put everything under smtpd_recipient_restrictions. To add additional restrictions, refer to the example I provided earlier: # do not include filter service IPs in mynetworks mynetworks = 127.0.0.0/8 ... smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination ... other restrictions here ... check_client_access cidr:/etc/postfix/filter_service reject Important Note: the various check_client_access, reject_rbl_client, various helo checks, and reject_unauth_pipelining restrictions will see the filter service connection info - not the original sender - so they are quite limited in usefulness to you. You could use reject_rhsbl_sender to reject bad sender domains if you can find a service that you consider trustworthy enough for rejections. -- Noel Jones I agree, the simpler the better. With the cidr file, i ONLY want to accept email from this filter service meaning do i need to put the 0.0.0.0/0 REJECT at the end of the list? Vernon
Re: Restrict external hosts
Vernon A. Fort wrote: I agree, the simpler the better. With the cidr file, i ONLY want to accept email from this filter service meaning do i need to put the 0.0.0.0/0 REJECT at the end of the list? Vernon The reject after the check_client_access takes care rejecting any client not permitted by the cidr table (or other rules), and makes it clear at a glance that nothing else will be accepted. That said, adding 0.0.0.0/0 REJECT at the end of the cidr table isn't exactly wrong, just unnecessary. -- Noel Jones
Re: Prioritising outgoing mail
Hi all, Would it be possible to add an extension to the user's address, e.g. user+s...@example.com, that would be mapped through a separate transport (e.g. the slow: as suggested in the man page), and be rewritten by trivial-rewrite to u...@example.com before being sent out. An option like this would do the job for me. It would allow me to easily maintain my maillist, rewriting addresses on the fly when creating the mails, and allowing regular mails to be handled with priority. And any ideas on how/where such a slow: transport (with a limited number of smtp daemons to be started) would be configured? I can't find anything about this in the man pages. Except that it is possible. Wouter. On Tue, 2009-03-03 at 11:25 +0800, Wouter van Marle wrote: On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote: On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote: Use a custom transport for these messages with a low concurrency limit, You mean like installing sendmail or so in parallel to postfix and then have sendmail send out the lower-priority mails? No I mean a Postfix transport, as in transport(5) and master(5). The problem of a transport map (I have just read the man page, which as usual is highly technical so I am not sure whether I fully understand the purpose and working of transport maps) is that there is a huge overlap between receivers of the low-priority mail list and regular e-mail receivers. Most of the regular e-mail receivers also receive this mail list. Many of my mail list receivers are on common domains like gmail.com and yahoo.com, thus this would slow down all other mails to those domains as well, even if they are not part of the mail list. Setting it per recipient is not a good idea because of maintenance issues (keeping mail list and transport map in sync), and because of the regular mails that may be sent to those recipients while a mail list run is in progress. The idea of using a slow: transport as suggested in the transport(5) man page (without elaborating unfortunately...) to limit the number of smtp deamons that sounds like the way to go to me. Then I can reserve 80 deamons for the mail list, or maybe 50, enough to saturate my uplink - still allowing regular mails to have an smtp available to be handled immediately. This appears to me a way to let the other mails jump the queue and be processed with priority. That there is little bandwidth available is not too much of an issue, then it might take a minute instead of seconds to send out, still a major improvement of the hours it may take in the current situation. or use traffic shaping in the TCP stack to limit the bandwidth per SMTP connection. And how would that get certain mails out with priority? It sounds to me like this would slow down the overall process. I have up to 100 smtp processes running at a time, but as long as new mails end up at the back of the queue still no progress there. They have to come first. It would not, but you won't saturate the entire link with any given email, leaving enough room for other traffic. If you can limit the concurrency of this particular message, then you'll have some bandwidth left over for other messages. I don't like that idea very much: when I have only a few mails to send out, I want them to go with the maximum speed possible. I have 2 Mbit available, so with 100 smtp connections could limit it to say 20 kbit per smtp process. But that would leave the rest of my bandwidth idle when there are less than 100 active smtp connections, which is the case like 90% of the time. Wouter.
Re: Prioritising outgoing mail
On Tue, Mar 03, 2009 at 11:25:55AM +0800, Wouter van Marle wrote: On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote: On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote: Use a custom transport for these messages with a low concurrency limit, You mean like installing sendmail or so in parallel to postfix and then have sendmail send out the lower-priority mails? No I mean a Postfix transport, as in transport(5) and master(5). The problem of a transport map (I have just read the man page, which as usual is highly technical so I am not sure whether I fully understand the purpose and working of transport maps) is that there is a huge overlap between receivers of the low-priority mail list and regular e-mail receivers. Most of the regular e-mail receivers also receive this mail list. You may need to do sender-dependent routing for this sender, and inject the mail into a different queue, or get the originating system to do this directly. It would not, but you won't saturate the entire link with any given email, leaving enough room for other traffic. If you can limit the concurrency of this particular message, then you'll have some bandwidth left over for other messages. I don't like that idea very much: when I have only a few mails to send out, I want them to go with the maximum speed possible. I have 2 Mbit available, so with 100 smtp connections could limit it to say 20 kbit per smtp process. But that would leave the rest of my bandwidth idle when there are less than 100 active smtp connections, which is the case like 90% of the time. Does limiting bandwidth for small messages signicantly impact delivery latency? Also who said you should divide the bandwidth 100-fold? You give the slow transport 5 parallel threads, and up to half the bandwidth, so each channel gets 10% of the bandwidth. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Spam attacks
W dniu 2009-03-03 08:25, Dave Johnson pisze: Hi all Is there anyway of stopping the from j...@foo.com mailto:from...@foo.com to j...@foo.com spam attacks? Hi Without knowing your config it's hard to say what are you already doing. Are you using SASL authentication? If not, have a look here: http://www.postfix.org/SASL_README.html#server_sasl To get really useful help (not just speculations) you have to read http://www.postfix.org/DEBUG_README.html#mail Pawel Lesniak
