Re: conversation with ... timed out while sending end of data -- message may be sent more than once
On Wed, 15 Jun 2011 08:39:11 +0200, Ralf Hildebrandt wrote: * Benny Pedersen : fail2ban could be ones friend if postfix have this fail2ban then just grep logs for outgoing mails that failed pr ip, and add this header ignore pr cidr maps Yeah, that's a great idea! it is ?, oh thanks :-)
Re: conversation with ... timed out while sending end of data -- message may be sent more than once
Am 15.06.2011 08:39, schrieb Ralf Hildebrandt: > * Benny Pedersen : > >> fail2ban could be ones friend if postfix have this >> >> fail2ban then just grep logs for outgoing mails that failed pr ip, >> and add this header ignore pr cidr maps > > Yeah, that's a great idea! > but what if there are other reasons, ok it doesnt hurt to much to remove dkim sigs, but the admin should be informed to this, or maybe it should expire, as far i remember this can be done with fail2ban too ( but i may fail here ) -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Send mail to local users only
Hello, I've a postfix 2.5.1 with system users. I need to restrict one
user to be able to send mail to local users only.
My conf:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1d
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
inet_interfaces = all
mail_owner = postfix
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
maximal_queue_lifetime = 2d
message_size_limit = 5120
mydestination = local domains list
myhostname = mail.domain.tld
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.0/24
myorigin = /etc/mailname
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/recipient_relayhost
Someone can point me to the right direction?
Thanks.
Temporary stopping external incoming emails
Hello I would like to stop incoming/outgoing email to our site without stopping internal emails exchange. my configuration is quite classic INTERNET | | MX SERVER | | INTERNAL MAILHUB | | USERS'S MUAs What I precisely wanted to do is : stop email flow between my mailhub and the MX server but not stop internal email service for our users. Also I would like the MX server still accept incoming emails from the Internet and keep them in its queue to deliver later when I restart normal service. Is it feasible ? Thanks a lot
Re: Temporary stopping external incoming emails
On 15/06/2011 11:19, Frank Bonnet wrote: Hello I would like to stop incoming/outgoing email to our site without stopping internal emails exchange. my configuration is quite classic INTERNET | | MX SERVER | | INTERNAL MAILHUB | If you want to stop MX server from sending emails to Internal mailhub I would block port 25 on mailhub with IPTABLES only from MX Server's IP. MX will queue emails and resent them to mailhub one you reopen the port in Mailhub.
Re: conversation with ... timed out while sending end of data -- message may be sent more than once
On Wednesday June 15 2011 05:42:36 Noel Jones wrote: > At this time I'm inclined to set this aside. The DKIM bug > doesn't seem to be widespread; there is no compelling case to > add a new workaround right now. Indeed the situation has much improved in the past year or two. Many sites have turned off smtp fixups or upgraded their ASA firmware or both. It also helps to send mail to postmasters of affected sites with a pointer to Ralf's web page and the Heise article, and suggest turning off the (mis)feature. Perhaps the incentive was when they started missing some of the mail from gmail.com and the like. Mark
Re: conversation with ... timed out while sending end of data -- message may be sent more than once
Victor Duchovni: > On Tue, Jun 14, 2011 at 08:05:24PM -0500, Noel Jones wrote: > > > I was thinking a setting integrated with smtp_pix_workarounds would be more > > automatic, with little maintenance once configured. > > Given that the banner detection is incomplete (some pixen are not > obviously such) one still needs manual configuration for some cases, > so I am not convinced that any new feature is warranted, the receiving > systems need to be incented to fix their bug. If enough "big mailers" sign their email (gmail, yahoo, etc.) then that will provide the incentive. Wietse
Error: timeout exceeded (in reply to end of DATA command)
Hi All, I manage a local intranet mail server which collects mails from our local users and sends them all via our public mail hub server. Everything was fine until few weeks ago. Some small part of our emails (about 10%) hangs in mail's server queue with error: timeout exceeded (in reply to end of DATA command)). Some emails stay in queue untill timeout expires (3 days) and returns to a sender with error. There are emails which stay in queue for a few hours (with the same error) but after serveral retries finally leave our server and reach recepients. Noticed following facts: - every timeout error is: (in reply to end of DATA command), there are no other errors - problem does not depend on email size (there were delayed emails with size range from 1kb to 5mb) Turned off: tcp window scalling, tcp ecn, smtp_connection_cache_on_demand - without success. In my opinion problem is on the mail hub server but I have no proofs. Talking with mail hub server's administrator but he said, that no others have problems with mails and that must be a problem with my email server. Now I stuck with my undelivered emails. Best regards. Tom. Logs System: Debian Wheezy postfix ver 2.8.3-1 -Queue ID- --Size-- Arrival Time -Sender/Recipient--- 4A9409365 4130 Tue Jun 14 09:59:13 a...@aaa.aaa.aa (host mailhub.aaa.aaa[NN.NN.N.NN] said: 421 4.4.2 mailhub.aaa.aaa Error: timeout exceeded (in reply to end of DATA command)) postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_queue_lifetime = 2d config_directory = /etc/postfix content_filter = vscan:[127.0.0.1]:10024 delay_warning_time = 24h disable_dns_lookups = yes header_checks = regexp:/etc/postfix/header_checks home_mailbox = Maildir/ inet_interfaces = merlin, 127.0.0.1 mailbox_command = /usr/bin/procmail -a "$EXTENSION" DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir mailbox_size_limit = 51200 maximal_queue_lifetime = 3d message_size_limit = 10240 mydestination = $myhostname, $myhostname.$mydomain, localhost, AAA mydomain = AAA.AAA.AAA myhostname = mynetworks = 127.0.0.0/8, NN.NN.NN.NN/24 myorigin = /etc/mailname notify_classes = bounce, 2bounce, policy, protocol, resource, software recipient_delimiter = + relayhost = smtp_host_lookup = native smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) transport_maps = hash:/etc/postfix/transport, regexp:/etc/sympa/transport
Combine access, transport, and header_checks?
Hi guys At the moment we use local spamfiltering on our MX smtp.terena.org. I would like to test out a new mail filtering product, which is a hosted solution. This system is configured to accept mail for our domains, and deliver it to smtp.terena.org. Eventually if this filter is deemed OK then our MX records would point to those boxes. For testing, I would like to have incoming mail for some users (including me) to be delivered to this remote filter. This could be achieved by transport maps such as: vis...@terena.org smtp:remote.filter.box But of course you would get a loop then, because the remote.filter.box is configured to deliver it back to the same host. So I guess I am looking for a sort of 'conditional' transport: only mail for vis...@terena.org that does not have a X-Spam-Flag header should be going to smtp:remote.filter.box. Any idea how to achieve this? FYI we run the Postfix that is in Ubuntu 8.04, which is 2.5.1. Thanks!!! -- Dyonisius Visser System & Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature
Re: Combine access, transport, and header_checks?
On 6/15/2011 7:21 AM, Dyonisius Visser wrote: > Hi guys > > At the moment we use local spamfiltering on our MX smtp.terena.org. > > I would like to test out a new mail filtering product, which is a hosted > solution. This system is configured to accept mail for our domains, and > deliver it to smtp.terena.org. > Eventually if this filter is deemed OK then our MX records would point > to those boxes. > > For testing, I would like to have incoming mail for some users > (including me) to be delivered to this remote filter. This could be > achieved by transport maps such as: > > vis...@terena.org smtp:remote.filter.box > > But of course you would get a loop then, because the remote.filter.box > is configured to deliver it back to the same host. > > So I guess I am looking for a sort of 'conditional' transport: only mail > for vis...@terena.org that does not have a X-Spam-Flag header should be > going to smtp:remote.filter.box. > > Any idea how to achieve this? Doesn't it give you pause that the company providing this filtering service doesn't provide you basic instructions on how to setup a proper test environment? Did they recommend you simply swap your MX record now and switch it back if you don't like the service? If so that would give me great pause. Why are you hesitant to name the service in question? Doing so may prove more beneficial than the question you've asked. -- Stan
Re: Error: timeout exceeded (in reply to end of DATA command)
Tomasz Iwanowski: > Hi All, > > I manage a local intranet mail server which collects mails from our local > users > and sends them all via our public mail hub server. > > Everything was fine until few weeks ago. Some small part of our emails (about > 10%) hangs > in mail's server queue with error: timeout exceeded (in reply to end of DATA > command)). > Some emails stay in queue untill timeout expires (3 days) and returns to a > sender with error. > There are emails which stay in queue for a few hours (with the same error) > but after serveral retries finally leave our server and reach recepients. > > Noticed following facts: > - every timeout error is: (in reply to end of DATA command), there are no > other errors > - problem does not depend on email size (there were delayed emails with size > range from 1kb to 5mb) > > Turned off: tcp window scalling, tcp ecn, smtp_connection_cache_on_demand - > without success. > > In my opinion problem is on the mail hub server but I have no proofs. > Talking with mail hub server's administrator but he said, that no others have > problems with mails > and that must be a problem with my email server. > Now I stuck with my undelivered emails. Try collecting a tcpdump recording. http://www.postfix.org/DEBUG_README.html#sniffer Command: # tcpdump -s 0 -w /file/name host server-ip-address and port 25 After some time, "kill -INT" the tcpdump process. Look in the logfile for a session that breaks, and find that session in the tcpdump recording. # tcpdump -nr /file/name | less Note the client tcp port, then extract that session: # tcpdump -nr /file/name -w file/name2 port xxx Then, contact Victor or me off-list. Wietse
Re: Combine access, transport, and header_checks?
Dyonisius Visser: > Hi guys > > At the moment we use local spamfiltering on our MX smtp.terena.org. > > I would like to test out a new mail filtering product, which is a hosted > solution. This system is configured to accept mail for our domains, and > deliver it to smtp.terena.org. > Eventually if this filter is deemed OK then our MX records would point > to those boxes. > > For testing, I would like to have incoming mail for some users > (including me) to be delivered to this remote filter. This could be > achieved by transport maps such as: > > vis...@terena.org smtp:remote.filter.box That does not work, because the filter almost certainly must talk to the remote SMTP client directly, so that it can do client IP address reputation stuff. Besides, it is a bad idea to use the same primary MX address AND port MX for unfiltered mail and for re-injected mail. Postfix describes better options in the MULTI_INSTANCE_README.html file. /---\ primary MTA with transport map < > back-end MTA \---filter--/ But, this means the filter won't see the client IP address and will therefore not be as effective. Wietse
Re: Combine access, transport, and header_checks?
On Wed, Jun 15, 2011 at 02:21:27PM +0200, Dyonisius Visser wrote: > So I guess I am looking for a sort of 'conditional' transport: only mail > for vis...@terena.org that does not have a X-Spam-Flag header should be > going to smtp:remote.filter.box. > > Any idea how to achieve this? The re-injection service for filtered mail must be a different IP:port pair than your MX service. The spam-filtering service should support XFORWARD, or else apply IP reputation to the IP address parsed out of the top-most Received header, when receiving mail indirectly via a set of known forwarders (such your test configuration). Your transport needs to enable sending XFORWARD data if the service supports this. -- Viktor.
Re: Error: timeout exceeded (in reply to end of DATA command)
On Wed, Jun 15, 2011 at 10:38:44AM -0400, Wietse Venema wrote: > Command: > # tcpdump -s 0 -w /file/name host server-ip-address and port 25 > > After some time, "kill -INT" the tcpdump process. > > Look in the logfile for a session that breaks, and find that session > in the tcpdump recording. > > # tcpdump -nr /file/name | less > > Note the client tcp port, then extract that session: > > # tcpdump -nr /file/name -w file/name2 port xxx The second tcpdump may also need the "-s 0" option to retain the full TCP payload. -- Viktor.
Re: Temporary stopping external incoming emails
On Wed, Jun 15, 2011 at 11:19:33AM +0200, Frank Bonnet wrote:
> INTERNET
>|
>|
>MX SERVER
>|
>|
>INTERNAL MAILHUB
>|
>|
> USERS'S MUAs
>
> What I precisely wanted to do is :
>
> stop email flow between my mailhub and the MX server
> but not stop internal email service for our users.
>
> Also I would like the MX server still accept incoming
> emails from the Internet and keep them in its queue
> to deliver later when I restart normal service.
If the internal mailhub is running Postfix, and uses a dedicated transport
(say "smtp" rather than "relay") to reach the MX server, while all internal
traffic uses other transports ("relay" or "virtual" or "local", ...) then
on the internal hub just set
defer_transports =
Likewise, if the mx server is running Postfix, and uses a dedicated
transport (say "relay" rather than "smtp") to reach the internal hub,
while all outbound traffic uses other transports (say "smtp") then on
the mx server just set
defer_transports =
Dedicating different transports to separate directions of mail flow is
a good idea anyway, so if that is not the case, make it so, and then
apply the above.
--
Viktor.
Milter does not process from postfix 2.7.1-1 (Debian Squeeze)
Hi there,
Spamass-milter has stopped processing messages from Postfix. I have
tested the milter socket and it works. To test that it worked I used :-
http://www.itg.uiuc.edu/itg_software/milter_watch/ and Spamass-milter
rejected the spammy messages.
The spam threshold on the spam milter is 11, and it seems that any
message is getting through. However, the backend SpamAssassin is
correctly tagging the messages as spam.
My objective of mailing this list is to either rule out Postfix config
problems or not.
Now I think I know that the milter is functioning, I would like someone
to check my config to ensure that is it correct. If some one has the time:-
# postconf -n | grep milter
milter_default_action = tempfail
non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock
smtpd_milters = unix:/clamav/clamav-milter.ctl,
unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock
The entire O/P of postconf -n is here:
# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks.regexp
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 2048
milter_default_action = tempfail
mime_header_checks = regexp:/etc/postfix/mime_header_checks
mydestination =
myhostname = klunky.co.uk
mynetworks = mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_helo_timeout = 60s
smtp_mail_timeout = 60s
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 50
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname,
reject_unlisted_recipient, reject_unlisted_sender,
regexp:/etc/postfix/helo.regexp, permit
smtpd_milters = unix:/clamav/clamav-milter.ctl,
unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated, reject_unauth_destination,
check_recipient_access cidr:/etc/postfix/whitelist, check_sender_access
hash:/etc/postfix/sender_checks, reject_non_fqdn_sender,
reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
reject_rbl_client sbl-xbl.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_tls_CAfile = /etc/ssl/xxx
smtpd_tls_cert_file = /etc/ssl/xx
smtpd_tls_key_file = /etc/ssl/xx
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
virtual_alias_maps =
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/mysql-virtual-mailbox-maps.cf
virtual_transport = dovecot-spamass
Best regards, S.
Re: Milter does not process from postfix 2.7.1-1 (Debian Squeeze)
On Wednesday, June 15, 2011 10:43:40 AM J4K wrote: > Hi there, > > Spamass-milter has stopped processing messages from Postfix. I have > tested the milter socket and it works. To test that it worked I used :- > http://www.itg.uiuc.edu/itg_software/milter_watch/ and Spamass-milter > rejected the spammy messages. > The spam threshold on the spam milter is 11, and it seems that any > message is getting through. However, the backend SpamAssassin is > correctly tagging the messages as spam. > > My objective of mailing this list is to either rule out Postfix config > problems or not. > > Now I think I know that the milter is functioning, I would like someone > to check my config to ensure that is it correct. If some one has the > time:- > > # postconf -n | grep milter > milter_default_action = tempfail > non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock > smtpd_milters = unix:/clamav/clamav-milter.ctl, > unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock Debian ships postfix running in a chroot by default. You either need to change master.cf to have it not run in the chroot or arrange to have both these sockets available within the chroot. This is (IME) generally easier to manage with TCP sockets than with Unix sockets. Scott K
Re: PATCH: postfix and linux-3.0
thank you for the quick response and patch! ron On 06/15/2011 01:48 AM, Wietse Venema wrote: Csillag Tamas: quoting from here: https://lkml.org/lkml/2011/5/29/204 "So what are the big changes? NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering..." In that case, the following patch will be sufficient for all supported Postfix releases. Wietse
Re: Milter does not process from postfix 2.7.1-1 (Debian Squeeze)
-- On 06/15/2011 06:17 PM, Scott Kitterman wrote: > On Wednesday, June 15, 2011 10:43:40 AM J4K wrote: >> Hi there, >> >> Spamass-milter has stopped processing messages from Postfix. I have >> tested the milter socket and it works. To test that it worked I used :- >> http://www.itg.uiuc.edu/itg_software/milter_watch/ and Spamass-milter >> rejected the spammy messages. >> The spam threshold on the spam milter is 11, and it seems that any >> message is getting through. However, the backend SpamAssassin is >> correctly tagging the messages as spam. >> >> My objective of mailing this list is to either rule out Postfix config >> problems or not. >> >> Now I think I know that the milter is functioning, I would like someone >> to check my config to ensure that is it correct. If some one has the >> time:- >> >> # postconf -n | grep milter >> milter_default_action = tempfail >> non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock >> smtpd_milters = unix:/clamav/clamav-milter.ctl, >> unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock > Debian ships postfix running in a chroot by default. You either need to > change > master.cf to have it not run in the chroot or arrange to have both these > sockets available within the chroot. This is (IME) generally easier to > manage > with TCP sockets than with Unix sockets. > > Scott K Hi Scott, This is not a new set-up. The system has been running unchanged since January this year. The server, with the three milters, was running perfectly well until a few weeks ago. All milters sockets are inside a place where Debian postfix can get to.
postfix bounce message configuration
Hi there, Sorry for the trivial question, I am a little confused what is a bounce message and how not to get these internal Postfix messages. From my server hub-dev-app01.dev.medplus.com, I send a message to hub-int-app01.dev.medplus.com. (They both running Postfix 2.3.x). Because my recipient address has a typo (correct domain but wrong address), hub-dev-app01.dev is sending the message sender the following message. This is correct behavior. Is the following an example of bounce message? Our user is not interested getting such messages, so I configured /etc/postfix/main.cf to assign empty value to "notify_class". notify_classes = But why am I still getting these messages? Thanks, Yan Received: by dir-dev-app01.dev.medplus.com (Postfix) id 7CACCC806D; Wed, 15 Jun 2011 18:02:59 + (UTC) Date: Wed, 15 Jun 2011 18:02:59 + (UTC) From: mailer-dae...@dir-dev-app01.dev.medplus.com (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: yz...@direct.dir-dev-app01.dev.medplus.com Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="30DADC8069.1308160979/dir-dev-app01.dev.medplus.com" Message-Id: <20110615180259.7caccc8...@dir-dev-app01.dev.medplus.com> This is a MIME-encapsulated message. --30DADC8069.1308160979/dir-dev-app01.dev.medplus.com Content-Description: Notification Content-Type: text/plain; charset=us-ascii This is the mail system at host dir-dev-app01.dev.medplus.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host dir-int-app01.dev.medplus.com[172.18.36.174] said: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) --30DADC8069.1308160979/dir-dev-app01.dev.medplus.com Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; dir-dev-app01.dev.medplus.com X-Postfix-Queue-ID: 30DADC8069 X-Postfix-Sender: rfc822; yz...@direct.dir-dev-app01.dev.medplus.com Arrival-Date: Wed, 15 Jun 2011 18:02:59 + (UTC) Final-Recipient: rfc822; non-ex...@direct.dir-int-app01.dev.medplus.com Original-Recipient: rfc822;non-ex...@direct.dir-int-app01.dev.medplus.com Action: failed Status: 5.1.1 Remote-MTA: dns; dir-int-app01.dev.medplus.com Diagnostic-Code: smtp; 550 5.1.1 : Recipient address rejected: User unknown in local recipient table Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system.
Re: postfix bounce message configuration
On 06/15/2011 08:13 PM, Zhou, Yan wrote: Hi there, Sorry for the trivial question, I am a little confused what is a bounce message and how not to get these internal Postfix messages. RFC 5321, Section 6.1, Reliable delivery and (error) replies: http://tools.ietf.org/html/rfc5321#section-6.1 They are not "internal" messages as such; according to the RFC, postfix is required to return undeliverable mail to the sender. So yes, postfix "generates" these messages, but it is required to do so. Since undeliverable mail is not a desirable outcome, postfix allows you to notify a chosen recipient of these occurences via the bounce_notice_recipient and notify_classes settings in main.cf. From my server hub-dev-app01.dev.medplus.com, I send a message to hub-int-app01.dev.medplus.com. (They both running Postfix 2.3.x). Because my recipient address has a typo (correct domain but wrong address), hub-dev-app01.dev is sending the message sender the following message. This is correct behavior. No, it is not. If the recipient was misspelled, the server should have REJECTed the message. Is the following an example of bounce message? Our user is not interested getting such messages, so I configured /etc/postfix/main.cf to assign empty value to "notify_class". notify_classes = But why am I still getting these messages? A (mandatory) bounce message is not the same as an (optional) notification of this event. Thanks, Yan Received: by dir-dev-app01.dev.medplus.com (Postfix) id 7CACCC806D; Wed, 15 Jun 2011 18:02:59 + (UTC) Date: Wed, 15 Jun 2011 18:02:59 + (UTC) From: mailer-dae...@dir-dev-app01.dev.medplus.com (Mail Delivery System) Note that the envelope (MAIL FROM) sender will be empty (<>), as per the RFC. This is to prevent bounce loops between MTAs. Subject: Undelivered Mail Returned to Sender Crystal clear. To: yz...@direct.dir-dev-app01.dev.medplus.com Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="30DADC8069.1308160979/dir-dev-app01.dev.medplus.com" Message-Id:<20110615180259.7caccc8...@dir-dev-app01.dev.medplus.com> This is a MIME-encapsulated message. --30DADC8069.1308160979/dir-dev-app01.dev.medplus.com Content-Description: Notification Content-Type: text/plain; charset=us-ascii This is the mail system at host dir-dev-app01.dev.medplus.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system This message, known as the bounce template, is fully configurable. See http://www.postfix.org/bounce.5.html for details. : host dir-int-app01.dev.medplus.com[172.18.36.174] said: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) --30DADC8069.1308160979/dir-dev-app01.dev.medplus.com Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; dir-dev-app01.dev.medplus.com X-Postfix-Queue-ID: 30DADC8069 X-Postfix-Sender: rfc822; yz...@direct.dir-dev-app01.dev.medplus.com Arrival-Date: Wed, 15 Jun 2011 18:02:59 + (UTC) Final-Recipient: rfc822; non-ex...@direct.dir-int-app01.dev.medplus.com Original-Recipient: rfc822;non-ex...@direct.dir-int-app01.dev.medplus.com Action: failed Status: 5.1.1 Remote-MTA: dns; dir-int-app01.dev.medplus.com Diagnostic-Code: smtp; 550 5.1.1 : Recipient address rejected: User unknown in local recipient table Postfix includes the reason the message was undeliverable; in this case, it was rejected by an upstream MTA. Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system. You're posting to a public mailing list, which is archived and freely viewable online. -- J.
Re: Send mail to local users only
On 06/15/2011 10:11 AM, mail...@securitylabs.it wrote:
Hello, I've a postfix 2.5.1 with system users. I need to restrict one
user to be able to send mail to local users only.
My conf:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1d
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
inet_interfaces = all
mail_owner = postfix
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
maximal_queue_lifetime = 2d
message_size_limit = 5120
mydestination = local domains list
myhostname = mail.domain.tld
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.0/24
myorigin = /etc/mailname
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/recipient_relayhost
Someone can point me to the right direction?
Use a restriction class:
http://www.postfix.org/RESTRICTION_CLASS_README.html
Note that this is SMTP only; it will not work with locally submitted
(sendmail) mail.
Thanks.
--
J.
Re: Milter does not process from postfix 2.7.1-1 (Debian Squeeze)
JKL: > On 06/15/2011 06:17 PM, Scott Kitterman wrote: > > On Wednesday, June 15, 2011 10:43:40 AM J4K wrote: > >> Hi there, > >> > >> Spamass-milter has stopped processing messages from Postfix. I have > >> tested the milter socket and it works. To test that it worked I used :- > >> http://www.itg.uiuc.edu/itg_software/milter_watch/ and Spamass-milter > >> rejected the spammy messages. > >> The spam threshold on the spam milter is 11, and it seems that any > >> message is getting through. However, the backend SpamAssassin is > >> correctly tagging the messages as spam. > >> > >> My objective of mailing this list is to either rule out Postfix config > >> problems or not. > >> > >> Now I think I know that the milter is functioning, I would like someone > >> to check my config to ensure that is it correct. If some one has the > >> time:- > >> > >> # postconf -n | grep milter > >> milter_default_action = tempfail > >> non_smtpd_milters = unix:/dkim-filter/dkim-filter.sock > >> smtpd_milters = unix:/clamav/clamav-milter.ctl, > >> unix:/spamass/spamass.sock, unix:/dkim-filter/dkim-filter.sock > > Debian ships postfix running in a chroot by default. You either need to > > change > > master.cf to have it not run in the chroot or arrange to have both these > > sockets available within the chroot. This is (IME) generally easier to > > manage > > with TCP sockets than with Unix sockets. > > > > Scott K > > Hi Scott, > > This is not a new set-up. The system has been running unchanged > since January this year. > > The server, with the three milters, was running perfectly well until a > few weeks ago. All milters sockets are inside a place where Debian > postfix can get to. When something stops working, then something has changed. You need to find out what has changed. Postfix does not change spontaneously. Wietse
RE: postfix bounce message configuration
Jeroen, Thanks, the way I see it is that the remote SMTP server rejects the message, so my local SMTP server is generating this bounce message to notify the sender. So, if I am sending a message that has invalid recipient address or the message exceeds limit, there is no way not getting these mandatory bounce messages. What I could configure is whether anyone else (such as postmaster) should be notified such bounce message, which is what "notify_classes" configuration for? That is in addition to notify the sender via bounce message. Is my understanding correct? Thanks, Yan Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system.
Re: postfix bounce message configuration
On 06/15/2011 09:48 PM, Zhou, Yan wrote: Jeroen, Thanks, the way I see it is that the remote SMTP server rejects the message, so my local SMTP server is generating this bounce message to notify the sender. So, if I am sending a message that has invalid recipient address or the message exceeds limit, there is no way not getting these mandatory bounce messages. What I could configure is whether anyone else (such as postmaster) should be notified such bounce message, which is what "notify_classes" configuration for? That is in addition to notify the sender via bounce message. Is my understanding correct? That is correct. Just unset bounce_notice_recipient and no bounce notifications will be sent. I was under the impression that you wanted to prevent sending out bounces at all. This is a Very Bad Idea. Thanks, Yan Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system. -- J.
RE: postfix bounce message configuration
I had postfix main.cf set like this. bounce_notice_recipient = But seeing following error. The default value is "postmaster", so this only disables bounce sent to "postmaster", not to the original sender, right? What am I missing? Jun 15 21:01:47 dir-dev-app01 postfix/bounce[28942]: fatal: bad string length 0 < 1: bounce_notice_recipient = Jun 15 21:01:47 dir-dev-app01 postfix/smtpd[28938]: disconnect from unknown[172.18.100.55] Jun 15 21:01:48 dir-dev-app01 postfix/master[28917]: warning: process /usr/libexec/postfix/bounce pid 28942 exit status 1 Jun 15 21:01:48 dir-dev-app01 postfix/master[28917]: warning: /usr/libexec/postfix/bounce: bad command startup -- throttling Jun 15 21:02:48 dir-dev-app01 postfix/bounce[28945]: fatal: bad string length 0 < 1: bounce_notice_recipient = Jun 15 21:02:49 dir-dev-app01 postfix/master[28917]: warning: process /usr/libexec/postfix/bounce pid 28945 exit status 1 Jun 15 21:02:49 dir-dev-app01 postfix/master[28917]: warning: /usr/libexec/postfix/bounce: bad command startup -- throttling Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system.
Re: postfix bounce message configuration
Zhou, Yan: > Jun 15 21:01:47 dir-dev-app01 postfix/bounce[28942]: fatal: bad string > length 0 < 1: bounce_notice_recipient = The bounce_notice_recipient value must not be empty. As documented, this is the address where copies of bounce notices are sent. As documented, the notify_classes parameter controls if Postfix sends copies of bounce messages sent. Wietse
receive_override_options=no_bcc_mappings
Hello,
For our setup here we needed to selectively disable BCC mappings without
disabling the other mappings. So attached is a patch that adds this capability
to receive_override_options . It does not change any other behavior.
The patch is against v2.8.3. I hope that it will be integrated in some next
version of the server.
Best regards & great software BTW
Luben Karavelovdiff -Naur postfix-2.8.3/html/postconf.5.html postfix-2.8.3-patched/html/postconf.5.html
--- postfix-2.8.3/html/postconf.5.html 2011-01-20 14:10:36.0 +0200
+++ postfix-2.8.3-patched/html/postconf.5.html 2011-05-30 19:32:50.889291872 +0300
@@ -7954,6 +7954,11 @@
recipients. This is typically specified BEFORE an external content
filter.
+no_bcc_mappings
+
+Disable automatic BCC (blind carbon-copy) recipients. This is
+typically specified BEFORE an external content filter.
+
no_header_body_checks
Disable header/body_checks. This is typically specified AFTER
diff -Naur postfix-2.8.3/man/man5/postconf.5 postfix-2.8.3-patched/man/man5/postconf.5
--- postfix-2.8.3/man/man5/postconf.5 2011-01-20 14:10:37.0 +0200
+++ postfix-2.8.3-patched/man/man5/postconf.5 2011-05-30 19:32:51.119274156 +0300
@@ -4507,6 +4507,9 @@
address masquerading, and automatic BCC (blind carbon-copy)
recipients. This is typically specified BEFORE an external content
filter.
+.IP "\fBno_bcc_mappings\fR"
+Disable automatic BCC (blind carbon-copy) recipients. This is
+typically specified BEFORE an external content filter.
.IP "\fBno_header_body_checks\fR"
Disable header/body_checks. This is typically specified AFTER
an external content filter.
diff -Naur postfix-2.8.3/proto/postconf.proto postfix-2.8.3-patched/proto/postconf.proto
--- postfix-2.8.3/proto/postconf.proto 2011-01-20 14:10:33.0 +0200
+++ postfix-2.8.3-patched/proto/postconf.proto 2011-05-30 19:30:44.529026685 +0300
@@ -3298,6 +3298,11 @@
recipients. This is typically specified BEFORE an external content
filter.
+no_bcc_mappings
+
+Disable automatic BCC (blind carbon-copy) recipients. This is
+typically specified BEFORE an external content filter.
+
no_header_body_checks
Disable header/body_checks. This is typically specified AFTER
diff -Naur postfix-2.8.3/src/global/input_transp.c postfix-2.8.3-patched/src/global/input_transp.c
--- postfix-2.8.3/src/global/input_transp.c 2008-01-08 22:36:13.0 +0200
+++ postfix-2.8.3-patched/src/global/input_transp.c 2011-05-30 19:12:47.012085544 +0300
@@ -74,6 +74,7 @@
"no_address_mappings", INPUT_TRANSP_ADDRESS_MAPPING,
"no_header_body_checks", INPUT_TRANSP_HEADER_BODY,
"no_milters", INPUT_TRANSP_MILTER,
+"no_bcc_mappings", INPUT_TRANSP_BCC,
0,
};
@@ -95,6 +96,9 @@
cleanup_flags &= ~CLEANUP_FLAG_FILTER;
if (transp_mask & INPUT_TRANSP_MILTER)
cleanup_flags &= ~CLEANUP_FLAG_MILTER;
+if (transp_mask & INPUT_TRANSP_BCC)
+ cleanup_flags &= ~CLEANUP_FLAG_BCC_OK;
+
if (msg_verbose)
msg_info("after %s: cleanup flags = %s",
myname, cleanup_strflags(cleanup_flags));
diff -Naur postfix-2.8.3/src/global/input_transp.h postfix-2.8.3-patched/src/global/input_transp.h
--- postfix-2.8.3/src/global/input_transp.h 2006-07-10 22:20:19.0 +0300
+++ postfix-2.8.3-patched/src/global/input_transp.h 2011-06-14 16:02:23.227251354 +0300
@@ -18,6 +18,7 @@
#define INPUT_TRANSP_ADDRESS_MAPPING (1<<1)
#define INPUT_TRANSP_HEADER_BODY (1<<2)
#define INPUT_TRANSP_MILTER (1<<3)
+#define INPUT_TRANSP_BCC (1<<4)
extern int input_transp_mask(const char *, const char *);
extern int input_transp_cleanup(int, int);
Re: receive_override_options=no_bcc_mappings
On Thu, Jun 16, 2011 at 12:44:36AM +0300, karave...@mail.bg wrote: > For our setup here we needed to selectively disable BCC mappings without > disabling the other mappings. So attached is a patch that adds this > capability to receive_override_options . It does not change any other > behavior. > > The patch is against v2.8.3. I hope that it will be integrated in some next > version of the server. A cleaner solution is multiple Postfix instances, each configured for the job at hand. http://www.postfix.org/MULTI_INSTANCE_README.html -- Viktor.
Re: receive_override_options=no_bcc_mappings
karave...@mail.bg: > Hello, > >For our setup here we needed to selectively disable BCC mappings >without disabling the other mappings. So attached is a patch that >adds this capability to receive_override_options . It does not >change any other behavior. I don't understand this. Apparently you can't use receive_override_options=no_address_mappings because you need virtual alias or canonical mapping on both sides of the filter? I would expect that such things either before or after the filter but not on both sides. Wietse >The patch is against v2.8.3. I hope that it will be integrated in >some next version of the server. > >Best regards & great software BTW Luben Karavelov > >[ Attachment, skipping... ] >
Re: receive_override_options=no_bcc_mappings
- Цитат от Wietse Venema (wie...@porcupine.org), на 16.06.2011 в 01:18 - karave...@mail.bg: Hello, For our setup here we needed to selectively disable BCC mappings without disabling the other mappings. So attached is a patch that adds this capability to receive_override_options . It does not change any other behavior. I don't understand this. Apparently you can't use receive_override_options=no_address_mappings because you need virtual alias or canonical mapping on both sides of the filter? I would expect that such things either before or after the filter but not on both sides. Wietse We do not use it before/after filter. The setup is that BCC mapping is only needed for sending outgoing mail (we send a copy to the "Sent" folder) so we enable BCC mapping by default (in main.cf) and disable it on default smtpd that handles incoming mail (we obviously need the other mappings there but do not need bcc mappings). The setup is somewhat unusual but it was decision made a long time ago. I would not argue if this is a good idea but the reason is every client (even clients with POP3 setup) to have copy of the sent mail. Until now it was working with separate instance of Postfix just for this (and separate instance for SPAM filtering etc). I find easier to care for one postfix config (instance) than a number of them. So I am in a process of consolidating them. Best regards Luben
Re: receive_override_options=no_bcc_mappings
Wietse: > Apparently you can't use receive_override_options=no_address_mappings > because you need virtual alias or canonical mapping on both sides > of the filter? karave...@mail.bg: > We do not use it before/after filter. The setup is that BCC mapping > is only needed for sending outgoing mail (we send a copy to the > "Sent" folder) so we enable BCC mapping by default (in main.cf) > and disable it on default smtpd that handles incoming mail (we > obviously need the other mappings there but do not need bcc mappings). I see. What about using this instead? /etc/postfix/master.cf smtpinet n - n - - smtpd -o sender_bcc_maps= submission inet n - n - - smtpd /etc/postfix/main.cf: sender_bcc_maps = maptype:mapname Or this? /etc/postfix/master.cf smtpinet n - n - - smtpd submission inet n - n - - smtpd -o sender_bcc_maps=maptype:mapname I am reluctant to add no_bcc_mappings, because that would make BCC mappings be a special case, and special cases make systems more difficult to understand. To avoid the special case, I'd have to also implement support for no_canonical_mappings, no_virtual_alias_mappings, and for no_address_masquerade. Otherwise, people would be wondering why they can turn off one feature and not the other. > The setup is somewhat unusual but it was decision made a long time > ago. I would not argue if this is a good idea but the reason is > every client (even clients with POP3 setup) to have copy of the > sent mail. Until now it was working with separate instance of > Postfix just for this (and separate instance for SPAM filtering > etc). I find easier to care for one postfix config (instance) than > a number of them. So I am in a process of consolidating them. Beware, as you add -o options in master.cf you have, it becomes harder to change one thing without breaking another thing. Wietse
Re: receive_override_options=no_bcc_mappings
- Цитат от Wietse Venema (wie...@porcupine.org), на 16.06.2011 в 02:44 - Wietse: Apparently you can't use receive_override_options=no_address_mappings because you need virtual alias or canonical mapping on both sides of the filter? karave...@mail.bg: We do not use it before/after filter. The setup is that BCC mapping is only needed for sending outgoing mail (we send a copy to the "Sent" folder) so we enable BCC mapping by default (in main.cf) and disable it on default smtpd that handles incoming mail (we obviously need the other mappings there but do not need bcc mappings). I see. What about using this instead? /etc/postfix/master.cf smtp inet n - n - - smtpd -o sender_bcc_maps= submission inet n - n - - smtpd /etc/postfix/main.cf: sender_bcc_maps = maptype:mapname Or this? /etc/postfix/master.cf smtp inet n - n - - smtpd submission inet n - n - - smtpd -o sender_bcc_maps=maptype:mapname I am reluctant to add no_bcc_mappings, because that would make BCC mappings be a special case, and special cases make systems more difficult to understand. To avoid the special case, I'd have to also implement support for no_canonical_mappings, no_virtual_alias_mappings, and for no_address_masquerade. Otherwise, people would be wondering why they can turn off one feature and not the other. The setup is somewhat unusual but it was decision made a long time ago. I would not argue if this is a good idea but the reason is every client (even clients with POP3 setup) to have copy of the sent mail. Until now it was working with separate instance of Postfix just for this (and separate instance for SPAM filtering etc). I find easier to care for one postfix config (instance) than a number of them. So I am in a process of consolidating them. Beware, as you add -o options in master.cf you have, it becomes harder to change one thing without breaking another thing. Wietse I thought that sender_bcc_maps/recipient_bcc_maps are options to the cleanup process, not smtpd. Will smtpd pass this informations somehow to the cleanup process? If it could be done in this way, I could use it and the patch is not needed. The special case was already there (CLEANUP_FLAG_BCC_OK). The patch just adds command line option for cleaning the flag separate from no_address_mappings. I think it is a special case in order to prevent sending multiple BCCs for one mail. Luben
Re: receive_override_options=no_bcc_mappings
On Wed, Jun 15, 2011 at 07:44:53PM -0400, Wietse Venema wrote: > > We do not use it before/after filter. The setup is that BCC mapping > > is only needed for sending outgoing mail (we send a copy to the > > "Sent" folder) so we enable BCC mapping by default (in main.cf) > > and disable it on default smtpd that handles incoming mail (we > > obviously need the other mappings there but do not need bcc mappings). > > I see. What about using this instead? > > /etc/postfix/master.cf > smtpinet n - n - - smtpd > -o sender_bcc_maps= > submission inet n - n - - smtpd > > /etc/postfix/main.cf: > sender_bcc_maps = maptype:mapname > > Or this? > > /etc/postfix/master.cf > smtpinet n - n - - smtpd > submission inet n - n - - smtpd > -o sender_bcc_maps=maptype:mapname As the OP observed, correctly, this won't work since bcc is done in cleanup, so a cleanup_service_name= override is required instead. However, a better solution is for the OP to not pursue the pointless "consolidation" (making a more complex mess out of a few simple parts). Just learn to manage multiple instances better. -- Viktor.
Re: receive_override_options=no_bcc_mappings
- Цитат от Victor Duchovni (victor.ducho...@morganstanley.com), на 16.06.2011 в 05:27 - Or this? /etc/postfix/master.cf smtp inet n - n - - smtpd submission inet n - n - - smtpd -o sender_bcc_maps=maptype:mapname As the OP observed, correctly, this won't work since bcc is done in cleanup, so a cleanup_service_name= override is required instead. However, a better solution is for the OP to not pursue the pointless "consolidation" (making a more complex mess out of a few simple parts). Just learn to manage multiple instances better. -- Viktor. Thanks for the suggestion, cleanup_service_name override is better and more clean solution compared to patched version. It simplifies the configuration. Thanks again Luben
Re: Temporary stopping external incoming emails
Thanks a lot Viktor.
Le 15/06/2011 17:38, Victor Duchovni a écrit :
On Wed, Jun 15, 2011 at 11:19:33AM +0200, Frank Bonnet wrote:
INTERNET
|
|
MX SERVER
|
|
INTERNAL MAILHUB
|
|
USERS'S MUAs
What I precisely wanted to do is :
stop email flow between my mailhub and the MX server
but not stop internal email service for our users.
Also I would like the MX server still accept incoming
emails from the Internet and keep them in its queue
to deliver later when I restart normal service.
If the internal mailhub is running Postfix, and uses a dedicated transport
(say "smtp" rather than "relay") to reach the MX server, while all internal
traffic uses other transports ("relay" or "virtual" or "local", ...) then
on the internal hub just set
defer_transports =
Likewise, if the mx server is running Postfix, and uses a dedicated
transport (say "relay" rather than "smtp") to reach the internal hub,
while all outbound traffic uses other transports (say "smtp") then on
the mx server just set
defer_transports =
Dedicating different transports to separate directions of mail flow is
a good idea anyway, so if that is not the case, make it so, and then
apply the above.
Re: Temporary stopping external incoming emails
well I do not use iptables because I run FreeBSD but I think it would be feasable with pf or ipfw Thanks Le 15/06/2011 11:31, mail...@securitylabs.it a écrit : On 15/06/2011 11:19, Frank Bonnet wrote: Hello I would like to stop incoming/outgoing email to our site without stopping internal emails exchange. my configuration is quite classic INTERNET | | MX SERVER | | INTERNAL MAILHUB | If you want to stop MX server from sending emails to Internal mailhub I would block port 25 on mailhub with IPTABLES only from MX Server's IP. MX will queue emails and resent them to mailhub one you reopen the port in Mailhub.
