possible localhost dns spoof attack
Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] After further analysis, I discovered that the traffic was not in fact being sent from 127.0.0.1. The packets were coming from: 113.167.239.162 Funnily enough, this IP's DNS resolves to the name localhost. Christian and I are suspicious of this. Could it be that this DNS name forms the basis of a simple DNS spoof attack that somehow confuses Postfix into thinking that the traffic comes from localhost and therefore, allows the relay to proceed? We would appreciate your thoughts. Jamie
Re: possible localhost dns spoof attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2013 11:32 AM, Jamie wrote: Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] After further analysis, I discovered that the traffic was not in fact being sent from 127.0.0.1. The packets were coming from: 113.167.239.162 Funnily enough, this IP's DNS resolves to the name localhost. Christian and I are suspicious of this. Could it be that this DNS name forms the basis of a simple DNS spoof attack that somehow confuses Postfix into thinking that the traffic comes from localhost and therefore, allows the relay to proceed? It is easy to add a directive to postfix that whitelists a hostname localhost, or a server HELOing as such. Of course, none of that is in the default config. We can never be sure unless you provide postfix logging of the actual attempt, and you post your configuration. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLJkJAAoJEJPfMZ19VO/1svAQAIMtiHus2nuvH6Re+GtTPud7 ZJRLFqiWB094CIN00X4VqsAAVWvphN4ZKD2XpMmmR20oEfLQJT269RCvT/McwYVu 4BhugnhWtA1dTtrJ+A7qvxCDR2M6aCvvGaRDQJ0toUIDqYeGX28VtBuJlDuXIte0 dOLDhc5RMfAj8nEVSSAe7e/G/ArJiLlB724wVn9Scgm46Tdsu0+6uiseX0/WNpCM I0beqbrGvCD19npUSK46oqf+mYpcVIie1dtYLctkUld1nRPjlCLRGc+qNs24ISLe jkPSD/rwzdWpPaPKqtomrq07WAWl83+b3cm5ozxGYaAGqP/C/DRRGSVN15lyYdpz 0BzA1FA8TWwoysXuFKO+g5zZVD2rnnTFdvMuk7fcNJerh5OrGjXvzng+vShcm4P1 2ozzKmvM8y/8SezMNSLIn4CF/WXj6+DOi0sWe+D3bg4wvY6r3R5FGv3ZbY9guen/ f0TZoavUOKbJiUWTg1qOsLSutj/YWh48sbEh1ZDUlZwwUiMq2LYF+e1hq0xmSFG0 zwIJdlQhtjm9golbfGOlCJRQAeVXuaXRq3LkN9KqjyuaBCXcJFjA3dNDVFcDHVb8 WlaWYzvOs3fgSLwq7duWeb85Q0foanuJsYEu4d2hhOoA1jI2SmmgAWlPPDJTsqiO AcHapP+4xGBm6bj0IUXH =0li3 -END PGP SIGNATURE-
Re: possible localhost dns spoof attack
On Feb 26, 2013, at 11:32 AM, Jamie wrote: Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] Are you sure of that? I assume that Postfix is getting the peer IP address from the socket, _not_ doing a lookup of the HELO name offered by the SMTP client, as that would be useless and confusing. Do you have any web server/PHP stuff on the same machine that might have been exploited instead? That would make the SMTP connection actually come from 127.0.0.1. Borja.
Re: possible localhost dns spoof attack
Borja I am pretty sure of it. After I blocked the ip address, the spam stopped coming. It is no co-incidence that 113.167.239.162 resolves to localhost (see: http://remote.12dt.com/ for confirmation). I am fairly certain that our mail server has not been hacked. Regards Jamie On 2013/02/26 1:19 PM, Borja Marcos wrote: On Feb 26, 2013, at 11:32 AM, Jamie wrote: Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] Are you sure of that? I assume that Postfix is getting the peer IP address from the socket, _not_ doing a lookup of the HELO name offered by the SMTP client, as that would be useless and confusing. Do you have any web server/PHP stuff on the same machine that might have been exploited instead? That would make the SMTP connection actually come from 127.0.0.1. Borja.
Re: reject empty sender address for authenticated users
W dniu 26.02.2013 02:27, Wietse Venema pisze:
Piotr Rotter:
W dniu 26.02.2013 01:56, Wietse Venema pisze:
Piotr Rotter:
Hello,
Can I set postfix to reject empty sender address for authenticated users.
I want to disallow this:
235 2.7.0 Authentication successful
MAIL FROM:
250 2.1.0 Ok
You could use reject_authenticated_sender_login_mismatch and require
that authenticated users use their own email address.
Wietse
Hello,
Thanks for advise, but I already use
reject_authenticated_sender_login_mismatch with smtpd_sender_login_maps
query:
SELECT email FROM postfix_users WHERE email=CONVERT('%s' USING latin1)
UNION SELECT destination FROM postfix_virtual WHERE email=CONVERT('%s'
USING latin1) AND ( type = 'alias' OR type = 'mismatch' );
But still empty sender adress for authenticated users are possible. My
restrictions on submission look like that:
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,reject_authenticated_sender_login_mismatch,permit_sasl_authenticated,$REJECT_NOAUTH,reject
X_ORIGINAL=check_recipient_access pcre:/etc/postfix/x-original.pcre
/etc/postfix/x-original.pcre :
/.*/ 550 Wymagana autoryzacja/Authorization required
Re: possible localhost dns spoof attack
Am 26.02.2013 12:35, schrieb Jamie: Borja I am pretty sure of it. After I blocked the ip address, the spam stopped coming. It is no co-incidence that 113.167.239.162 resolves to localhost (see: http://remote.12dt.com/ for confirmation). I am fairly certain that our mail server has not been hacked. Regards Jamie On 2013/02/26 1:19 PM, Borja Marcos wrote: On Feb 26, 2013, at 11:32 AM, Jamie wrote: Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] Are you sure of that? I assume that Postfix is getting the peer IP address from the socket, _not_ doing a lookup of the HELO name offered by the SMTP client, as that would be useless and confusing. Do you have any web server/PHP stuff on the same machine that might have been exploited instead? That would make the SMTP connection actually come from 127.0.0.1. Borja. Hi, double check that no webserver script is injecting mail via localhost etc, for other case dig -x 113.167.239.162 ; DiG 9.7.0-P1 -x 113.167.239.162 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53155 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.239.167.113.in-addr.arpa. IN PTR ;; ANSWER SECTION: 162.239.167.113.in-addr.arpa. 86400 IN PTR localhost. thats not very rare in the internet you may solve i.e it with smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, ... check_reverse_client_hostname_access hash:/etc/postfix/reverse_client_hostname_access ... /etc/postfix/reverse_client_hostname_access localhost REJECT your ptr record points to localhost fix it Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: possible localhost dns spoof attack
As requested, here is our configuration. I added the helo restrictions
after seeing the relay problem, but it didn't help.
*** main.cf ***
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate delayed mail warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_loglevel = 1
##smtpd_tls_cert_file = /etc/ssl/certs/mailarchiva.com.crt
##smtpd_tls_key_file = /etc/ssl/private/mailarchiva.key
#smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
##smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_cert_file = /root/certs/archiva.pem
smtpd_tls_key_file = /root/certs/mailarchiva.key
smtpd_tls_CAfile = /root/certs/rootcerts.pem
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = medium, high
smtpd_recipient_restrictions =
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl2_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_auth_only = no
smtpd_use_tls=no
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = serve.stimulussoft.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $mydomain, $myhostname, serve.mailarchiva.com,
serve.stimulussoft.com, localhost.stimulussoft.com, localhost,
mailarchiva.com
relaydomain = $mydomain
relayhost =
#mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_command =
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
#disable_dns_lookups = yes
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
header_checks = pcre:/etc/postfix/header_checks
#content_filter = scan:127.0.0.1:10025
#receive_override_options = no_address_mappings
smtpd_tls_req_ccert = no
smtp_tls_req_ccert = no
virtual_alias_domains = hash:/etc/postfix/mydomains
virtual_alias_maps = hash:/etc/postfix/virtual
content_filter = smtp-amavis:[127.0.0.1]:10024
#transport_maps = hash:/etc/postfix/transport
smtp_host_lookup = dns, native
#milter_default_action = tempfail
#smtpd_milters = inet:127.0.0.1:8092
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_invalid_hostname
reject_non_fqdn_hostname
** master.cf
#
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: man 5 master).
#
# Do not forget to execute postfix reload after editing this file.
#
# ==
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==
smtp inet n - y - - smtpd
# 26 inet n - y - - smtpd
#submission inet n - - - - smtpd
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#smtps inet n - - - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#628 inet n - - - - qmqpd
pickupfifo n - - 60 1 pickup
-o content_filter=
-o receive_override_options=no_header_body_checks
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - - 300 1 oqmgr
tlsmgrunix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounceunix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verifyunix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - -
Re: possible localhost dns spoof attack
Am 26.02.2013 12:57, schrieb Jamie: As requested, here is our configuration. I added the helo restrictions after seeing the relay problem, but it didn't help. *** main.cf *** # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname snip do NOT post main.cf postconf -n shows the really active configuration and if you are missing there rules check for typos because they may look OK in the main.cf but ignored! signature.asc Description: OpenPGP digital signature
Re: possible localhost dns spoof attack
Robert Thanks for the ideas. I'll try out your recommendations. Like I said, as soon as I blocked the troublesome IP's the problem went away. Thus, it cannot be a local script. Furthermore, we are not even running Apache. We are running Tomcat with custom developed Java apps. I also ran tcpdump on localhost to see if there was traffic being received on localhost. Guess what? While the spamming was taking place there was no smtp traffic passing through on localhost port 25. Hi, double check that no webserver script is injecting mail via localhost etc, for other case dig -x 113.167.239.162 ; DiG 9.7.0-P1 -x 113.167.239.162 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53155 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.239.167.113.in-addr.arpa. IN PTR ;; ANSWER SECTION: 162.239.167.113.in-addr.arpa. 86400 IN PTR localhost. thats not very rare in the internet you may solve i.e it with smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, ... check_reverse_client_hostname_access hash:/etc/postfix/reverse_client_hostname_access ... /etc/postfix/reverse_client_hostname_access localhost REJECT your ptr record points to localhost fix it Best Regards MfG Robert Schetterer
Re: possible localhost dns spoof attack
Am 26.02.2013 13:04, schrieb Jamie: Robert Thanks for the ideas. I'll try out your recommendations. Like I said, as soon as I blocked the troublesome IP's the problem went away. Thus, it cannot be a local script. Furthermore, we are not even running Apache. We are running Tomcat with custom developed Java apps. I also ran tcpdump on localhost to see if there was traffic being received on localhost. Guess what? While the spamming was taking place there was no smtp traffic passing through on localhost port 25. Hi, double check that no webserver script is injecting mail via localhost etc, for other case dig -x 113.167.239.162 ; DiG 9.7.0-P1 -x 113.167.239.162 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53155 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.239.167.113.in-addr.arpa. IN PTR ;; ANSWER SECTION: 162.239.167.113.in-addr.arpa. 86400 IN PTR localhost. thats not very rare in the internet you may solve i.e it with smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, ... check_reverse_client_hostname_access hash:/etc/postfix/reverse_client_hostname_access ... /etc/postfix/reverse_client_hostname_access localhost REJECT your ptr record points to localhost fix it Best Regards MfG Robert Schetterer so my tip should help, please do not top post Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
lost connection with while sending RCPT TO
Hi, there is an error in mail log file when sending mail to some hotmail accounts log file error : relay=none, delay=0.65, delays=0.45/0.14/0/0.06, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mx2.hotmail.com[65.55.37.104] while sending RCPT TO) I want to know what is the reason for this error and how to solve it Thank you, -- Ingénieur Radwa Hamed radwa.ha...@auf.org Responsable Technique local du Campus Numérique Francophone (CNF) de l'Agence Universitaire de la francophonie (AUF) à l'Université Senghor Département Formations à Distance (FAD) Technologies de l'information et de la communication pour l'Education (TICE) 1, Place Ahmed Orabi,B.P 2 - 415 El Mancheya Alexandrie - Egypte Tél : ++ 203 48 43 229
Re: possible localhost dns spoof attack
Like I said, as soon as I blocked the troublesome IP's the problem went away. Thus, it cannot be a local script. Furthermore, we are not even running Apache. We are running Tomcat with custom developed Java apps. I also ran tcpdump on localhost to see if there was traffic being received on localhost. Guess what? While the spamming was taking place there was no smtp traffic passing through on localhost port 25. You should still recheck your mail server configuration, looks like your server is open relay? -- Eero
Re: lost connection with while sending RCPT TO
Radwa Hamed: there is an error in mail log file when sending mail to some hotmail accounts log file error : relay=none, delay=0.65, delays=0.45/0.14/0/0.06, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mx2.hotmail.com[65.55.37.104] while sending RCPT TO) I want to know what is the reason for this error and how to solve it http://mail.live.com/mail/postmaster.aspx Wietse
Re: possible localhost dns spoof attack
On 2/26/2013 7:52 AM, Eero Volotinen wrote: Like I said, as soon as I blocked the troublesome IP's the problem went away. Thus, it cannot be a local script. Furthermore, we are not even running Apache. We are running Tomcat with custom developed Java apps. I also ran tcpdump on localhost to see if there was traffic being received on localhost. Guess what? While the spamming was taking place there was no smtp traffic passing through on localhost port 25. You should still recheck your mail server configuration, looks like your server is open relay? -- Eero According to mxtoolbox his server is not an open relay. However the thing that would concern me is the session log your provided: connect from localhost.localdomain[127.0.0.1] Can you post your /etc/hosts and /etc/hostname please? Thanks -- smime.p7s Description: S/MIME Cryptographic Signature
Re: possible localhost dns spoof attack
On 2/26/2013 4:32 AM, Jamie wrote: Hi Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] I suspect your analysis is faulty. Please show postconf -n and unaltered log entries demonstrating the problem. After further analysis, I discovered that the traffic was not in fact being sent from 127.0.0.1. The packets were coming from: 113.167.239.162 Funnily enough, this IP's DNS resolves to the name localhost. There are several whole netblocks in Asia that resolve to localhost. [My guess is this is the ISP's effort to mark the netblock as home users rather than anything malicious. Seems too lame, too easy to detect, and too easy to block to be malicious. I could be wrong.] Postfix will log all connections from these hosts as unknown with the real IP address. If postfix logs a connection from 127.0.0.1, the connection *really is* from localhost. Maybe you were looking at a content_filter log line? Christian and I are suspicious of this. Could it be that this DNS name forms the basis of a simple DNS spoof attack that somehow confuses Postfix into thinking that the traffic comes from localhost and therefore, allows the relay to proceed? This won't fool postfix. Please post evidence before jumping to wild conclusions. -- Noel Jones
Re: possible localhost dns spoof attack
Sure... the log entries are not altered in any way.
*** /etc/hostname ***
serve.stimulussoft.com
*** /etc/hosts ***
127.0.0.1localhost.localdomain localhost
71.6.200.51serve.stimulussoft.com serve.mailarchiva.com
*** postfix configuration ***
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
inet_interfaces = all
mailbox_command =
mailbox_size_limit = 0
mydestination = $mydomain, $myhostname, serve.mailarchiva.com,
serve.stimulussoft.com, localhost.stimulussoft.com, localhost,
mailarchiva.com
myhostname = serve.stimulussoft.com
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_host_lookup = dns, native
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
permit_sasl_authenticatedreject_invalid_hostname
reject_non_fqdn_hostname
smtpd_recipient_restrictions =
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /root/certs/rootcerts.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /root/certs/archiva.pem
smtpd_tls_key_file = /root/certs/mailarchiva.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = medium, high
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = no
tls_random_source = dev:/dev/urandom
virtual_alias_domains = hash:/etc/postfix/mydomains
virtual_alias_maps = hash:/etc/postfix/virtual
On 2013/02/26 3:32 PM, Deeztek.com Support wrote:
On 2/26/2013 7:52 AM, Eero Volotinen wrote:
Like I said, as soon as I blocked the troublesome IP's the problem went
away. Thus, it cannot be a local script. Furthermore,
we are not even running Apache. We are running Tomcat with custom
developed
Java apps.
I also ran tcpdump on localhost to see if there was traffic being
received
on localhost. Guess what? While the spamming was taking place
there was no smtp traffic passing through on localhost port 25.
You should still recheck your mail server configuration, looks like
your server is open relay?
--
Eero
Re: possible localhost dns spoof attack
On 2/26/2013 8:53 AM, Jamie wrote: On 2013/02/26 3:32 PM, Deeztek.com Support wrote: On 2/26/2013 7:52 AM, Eero Volotinen wrote: Like I said, as soon as I blocked the troublesome IP's the problem went away. Thus, it cannot be a local script. Furthermore, we are not even running Apache. We are running Tomcat with custom developed *** /etc/hosts *** 127.0.0.1localhost.localdomain localhost As I suspected. I really believe that the suspicious traffic was coming from your box. Even if that public IP address resolves to localhost it's not resolving to localhost.localdomain as what the transaction log you sent indicated. That's hard coded in your box and it doesn't matter what DNS says. It's possible that public IP was a CC server and blocking it may have stopped the spam but the problem still remains. Please run the following to install and run chkrootkit to see if it finds anything: sudo aptitude install -y chkrootkit sudo chkrootkit -- smime.p7s Description: S/MIME Cryptographic Signature
Re: possible localhost dns spoof attack
Noel Jones: Earlier today I noticed a spammer using my Postfix server as a relay to send out spam. This was puzzling because i had all requisite anti relay host settings applied. Further, it was particularly alarming that Postfix seemed to be receiving the spam messages from localhost as indicated: connect from localhost.localdomain[127.0.0.1] ... If postfix logs a connection from 127.0.0.1, the connection *really is* from localhost. Maybe you were looking at a content_filter log line? I agree (and I wrote this code). The Postfix SMTP server logs connect from localhost.localdomain[127.0.0.1] when the connection is made from a local IP address (for example a local content filter, or a local application) and you have localhost.localdomain in /etc/hosts (or in DNS but that's unlikely). In contrast, the Postfix SMTP server logs connect from unknown[x.x.x.x] for connections that come from a remote IP address that has a PTR record of localhost. Also, the Postfix SMTP server is hard-coded to log connect from localhost[127.0.0.1] (no localdomain here) when invoked as sendmail -bs. In that case there is no IP address and I just make it up. Only the first of the three forms matches what you report. Wietse
Re: possible localhost dns spoof attack
I ran chkrootki with clean results. For kicks: I sent a test email to myself from a web mail client. It seems connect from localhost.localdomain[127.0.0.1] is outputted under normal circumstances. Thus, it must be something to do with the way in which postfix passed mails along to the antivirus, antispam scaners. I am just not sure how to interpret the Postfix logs. The question remains... how did this spammer use this server as an open relay when its been disallowed in the configuration. Feb 26 06:46:26 serve postfix/smtpd[12617]: connect from out1-smtp.messagingengine.com[66.111.4.25] Feb 26 06:46:26 serve postfix/smtpd[12617]: setting up TLS connection from out1-smtp.messagingengine.com[66.111.4.25] Feb 26 06:46:27 serve postfix/smtpd[12617]: Anonymous TLS connection established from out1-smtp.messagingengine.com[66.111.4.25]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) Feb 26 06:46:27 serve postfix/smtpd[12617]: 3E42E10DB6: client=out1-smtp.messagingengine.com[66.111.4.25] Feb 26 06:46:27 serve postfix/cleanup[12621]: 3E42E10DB6: message-id=1361889074.16425.140661197113865.2ecdd...@webmail.messagingengine.com Feb 26 06:46:27 serve postfix/qmgr[19586]: 3E42E10DB6: from=jam...@fastmail.fm, size=2433, nrcpt=1 (queue active) Feb 26 06:46:27 serve postfix/smtpd[12617]: disconnect from out1-smtp.messagingengine.com[66.111.4.25] root@serve:/var/log# tail mail.log Feb 26 06:46:32 serve postfix/smtpd[12638]: connect from localhost.localdomain[127.0.0.1] Feb 26 06:46:32 serve postfix/smtpd[12638]: 597DB10DC1: client=localhost.localdomain[127.0.0.1] Feb 26 06:46:32 serve postfix/cleanup[12621]: 597DB10DC1: message-id=1361889074.16425.140661197113865.2ecdd...@webmail.messagingengine.com Feb 26 06:46:32 serve postfix/smtpd[12638]: disconnect from localhost.localdomain[127.0.0.1] Feb 26 06:46:32 serve postfix/qmgr[19586]: 597DB10DC1: from=jam...@fastmail.fm, size=2858, nrcpt=1 (queue active) Feb 26 06:46:32 serve amavis[26243]: (26243-14) Passed CLEAN, [66.111.4.25] [66.111.4.25] jam...@fastmail.fm - ja...@stimulussoft.com, Message-ID: 1361889074.16425.140661197113865.2ecdd...@webmail.messagingengine.com, mail_id: Qgl96w7X5Ph8, Hits: -1.791, size: 2433, queued_as: 597DB10DC1, 5037 ms Feb 26 06:46:32 serve postfix/smtp[12624]: 3E42E10DB6: to=ja...@stimulussoft.com, relay=127.0.0.1[127.0.0.1]:10024, delay=5.2, delays=0.12/0/0/5, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 597DB10DC1) Feb 26 06:46:32 serve postfix/qmgr[19586]: 3E42E10DB6: removed Feb 26 06:46:32 serve postfix/local[12641]: 597DB10DC1: to=ja...@stimulussoft.com, relay=local, delay=0.07, delays=0.04/0/0/0.03, dsn=2.0.0, status=sent (delivered to maildir) Feb 26 06:46:32 serve postfix/qmgr[19586]: 597DB10DC1: removed
Re: possible localhost dns spoof attack
Jamie: For kicks: I sent a test email to myself from a web mail client. It seems connect from localhost.localdomain[127.0.0.1] is outputted under normal circumstances. Thus, it must be something to do with the way in which postfix passed mails along to the antivirus, antispam scaners. I am just not sure how to interpret the Postfix logs. The question remains... how did this spammer use this server as an open relay when its been disallowed in the configuration. You ignored the mailing list welcome message. Stop ignoring it (see below) if you want to be helped by people with a clue. Wietse TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix.
Running namecache service on postfix server?
I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this?
Re: possible localhost dns spoof attack
On 2013/02/26 4:59 PM, Deeztek.com Support wrote: in your /etc/hosts file if you were to change it to the actual servername.domain.tld of your server, then the log should report the actual server name vs. localhost.localdomain. I would unblock the IP address and see if the same thing happens and this time look for suspicious processes in your box. I unblocked the IP and the problem came back. Is you outbound traffic on your firewall filtered or is everything allowed outbound? Everything is allowed outbound. Also maybe look at the type of traffic going back and forth with that suspicious IP to hopefully determine what's going on (snort?). This doesn't seem like a postfix issue any longer. Thanks for your help. I will look at it further, but I am pretty certain that our machine isn't compromised.
Re: Running namecache service on postfix server?
Am 26.02.2013 15:58, schrieb Robert Moskowitz: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? virtually anybody with a large mail/connection traffic has a chaching nameserver on his mailservers running, it is common practice signature.asc Description: OpenPGP digital signature
Re: Running namecache service on postfix server?
On 02/26/2013 10:10 AM, Reindl Harald wrote: Am 26.02.2013 15:58, schrieb Robert Moskowitz: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? virtually anybody with a large mail/connection traffic has a chaching nameserver on his mailservers running, it is common practice thanks. One more piece learned.
Re: possible localhost dns spoof attack
On 2/26/2013 8:45 AM, Jamie wrote: I ran chkrootki with clean results. For kicks: I sent a test email to myself from a web mail client. It seems connect from localhost.localdomain[127.0.0.1] is outputted under normal circumstances. Thus, it must be something to do with the way in which postfix passed mails along to the antivirus, antispam scaners. I am just not sure how to interpret the Postfix logs. The question remains... how did this spammer use this server as an open relay when its been disallowed in the configuration. There's no shortage of folks on this list who can help you interpret the logs once you share them. You need to show us postconf -n and logs of the suspect mail. It's helpful to examine the evidence before drawing conclusions. That's called guessing, and there's been a lot of that in this thread. Feb 26 06:46:26 serve postfix/smtpd[12617]: connect from out1-smtp.messagingengine.com[66.111.4.25] ... snip ... Feb 26 06:46:32 serve postfix/local[12641]: 597DB10DC1: to=ja...@stimulussoft.com, relay=local, delay=0.07, delays=0.04/0/0/0.03, dsn=2.0.0, status=sent (delivered to maildir) Feb 26 06:46:32 serve postfix/qmgr[19586]: 597DB10DC1: removed Nice example of a normal mail, but not particularly useful. Please show all those same log entries from a suspect message, along with your current postconf -n output. For further help, please see: http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
Re: reject empty sender address for authenticated users
On Tue, Feb 26, 2013 at 01:50:34AM +0100, Piotr Rotter wrote: Can I set postfix to reject empty sender address for authenticated users. Null-sender must be accepted. There are several occasions where a MUA may send them, for example DSN mandates its usage sometimes. RFC 6409 specifies: | Note that a null return path, that is, MAIL FROM:, is permitted and | MUST NOT, in itself, be cause for rejecting a message. (MUAs need to | generate null return-path messages for a variety of reasons, including | disposition notifications.) Bastian -- Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown
Re: Running namecache service on postfix server?
On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. Consider not only deploying a local cache, but also making sure that it is DNSSEC aware. I recommend unbound from nlnetlabs.nl. Of course you don't have to use DANE and TLS, but you still benefit from a local cache regardless. Setting up DNSSEC on a local unbound cache that forwards all queries to an upstream server boils down to: /etc/unbound/unbound.conf server: ... other server settings ... # # Local (non-public) cache listens only on the loopback interface. # interface: 127.0.0.1 interface: ::1 access-control: 127.0.0.1 allow access-control: ::1 allow # # Enable internal non-DNSSEC RFC 1918 nets. # local-zone: 10.in-addr.arpa. nodefault domain-insecure: 10.in-addr.arpa. # local-zone: 16.172.in-addr.arpa. nodefault domain-insecure: 16.172.in-addr.arpa. # local-zone: 17.172.in-addr.arpa. nodefault domain-insecure: 17.172.in-addr.arpa. ... # local-zone: 30.172.in-addr.arpa. nodefault domain-insecure: 30.172.in-addr.arpa. # local-zone: 31.172.in-addr.arpa. nodefault domain-insecure: 31.172.in-addr.arpa. # local-zone: 168.192.in-addr.arpa. nodefault domain-insecure: 168.192.in-addr.arpa. # # Internal domains may map to private addresses, # and may not be DNSSEC signed. # private-domain: example.com. domain-insecure: example.com. # # root zone key fingerprint, get your copy from a trusted source. # AND update it from time to time if and when the root zone key is # updated. # trust-anchor: . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 # Forward all requests to upstream server at 192.0.2.1 # This server must not forward queries for internal # names (forward or reverse) to the public internet. # forward-zone: name: . forward-addr: 192.0.2.1 -- Viktor.
Re: reject empty sender address for authenticated users
On Tue, Feb 26, 2013 at 05:43:45PM +0100, Bastian Blank wrote: On Tue, Feb 26, 2013 at 01:50:34AM +0100, Piotr Rotter wrote: Can I set postfix to reject empty sender address for authenticated users. Null-sender must be accepted. There are several occasions where a MUA may send them, for example DSN mandates its usage sometimes. IIRCDSN is only for MTAs, MUAs do MDN, which does not mandate null sender addresses. Rather, MDN replies don't elicit further MDN replies. -- Viktor.
Re: lost connection with while sending RCPT TO
On Tue, Feb 26, 2013 at 02:08:34PM +0200, Radwa Hamed wrote: there is an error in mail log file when sending mail to some hotmail accounts ... relay=none, delay=0.65, delays=0.45/0.14/0/0.06, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mx2.hotmail.com[65.55.37.104] while sending RCPT TO) I want to know what is the reason for this error and how to solve it First, note that the words delivery temporarily suspended mean that this error is the result of previous errors that lead to the suspension of message delivery to the destination. The error message is taken from the last failed delivery that caused delivery to be suspended. Delivery is suspended when multiple consecutive message deliveries are aborted by connection problems (not just invalid/refused recipients). The number of messages is by default the concurrency limit for the destination. Some users set very low concurrency limits for destinations such as Yahoo or Hotmail, hoping that this will help avoid rate limits imposed by the provider. One consequence of such low limits is that delivery is far more likely to be suspended in the face of a small burst of errors. This is especially likely if you configure a rate delay for the destination, which effectively sets the concurrency limit to 1. You'll get better help if you post your postconf -n configuration settings as requested in http://www.postfix.org/DEBUG_README.html#mail;. You should also look further back in your log and find the actual deliveries that trigger the problem (the ones that don't have delivery temporarily suspended in the error reason). You'll see how many consecutive failures of this sort it took to throttle (suspend) delivery to Hotmail. -- Viktor.
Re: Running namecache service on postfix server?
On Feb 26, 2013, at 17:51, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. Consider not only deploying a local cache, but also making sure that it is DNSSEC aware. I recommend unbound from nlnetlabs.nl. Of course you don't have to use DANE and TLS, but you still benefit from a local cache regardless. Another advantage of a local cache is that you can intercept or redirect DNS queries. We have a dedicated zone for our own DNS blacklist, for example, that redirects to rbldnsd on a different port. Postfix (and postscreen) query this local blacklist via DNS, just like they would with Spamhaus blacklists, the BRBL etc. We currently use BIND, but would recommend Unbound as well, that's what we'll be moving towards for DNSSEC support. HTH, Jona
Re: possible localhost dns spoof attack
On Tue, 26 Feb 2013 17:16:20 +0200 Jamie articulated: On 2013/02/26 4:59 PM, Deeztek.com Support wrote: in your /etc/hosts file if you were to change it to the actual servername.domain.tld of your server, then the log should report the actual server name vs. localhost.localdomain. I would unblock the IP address and see if the same thing happens and this time look for suspicious processes in your box. I unblocked the IP and the problem came back. Is you outbound traffic on your firewall filtered or is everything allowed outbound? Everything is allowed outbound. Also maybe look at the type of traffic going back and forth with that suspicious IP to hopefully determine what's going on (snort?). This doesn't seem like a postfix issue any longer. Thanks for your help. I will look at it further, but I am pretty certain that our machine isn't compromised. Jamie, I realize that sometimes debugging can be a stressful job. If you would read the documentation at http://www.postfix.org/DEBUG_README.html, specifically the section located at http://www.postfix.org/DEBUG_README.html#mail and follow the directions, it would save you a lot of work. Better yet, provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger. Post the complete, unmungled results here and the Postfix gurus can give you the assistance you need. The idea that you are pretty certain that our machine isn't compromised is certainly not comforting at all. If you are not positive, then you have a problem.
Filtering on a per-recipient domain basis
I'm running postfix 2.3.3 on Linux. I'd like to send mail to an external content filter based on the recipient address, which would be injected back into postfix on port 10027. My first attempt was check_recipient_access=regexp:/etc/postfix/esa ... with esa containing: # Send non-local mail to the ESA /\@local1\.edu$/ dunno /\@local2\.edu$/ dunno // FILTER smtp:[esa]:25 which didn't work when the mail had both internal and external recipients. I believe because as stated in the FILTER_README: * The same content filter is applied to all the recipients of a given message. So I then tried messing with transport_maps and then default_transport, but I don't think I can override these settings in port 10027 smtpd definition in master.conf (so I ended up with a mail loop). I believe I can accomplish this by using either the transport_maps or default_transport setting and configuring another instance of postfix listen on 10027 for the checked mail. Is this the best way of doing this, or is there an easier way? Thanks in advance, Rich
Re: Filtering on a per-recipient domain basis
Rich Bishop: I'm running postfix 2.3.3 on Linux. I'd like to send mail to an external content filter based on the recipient address, which would be injected back into postfix on port 10027. My first attempt was check_recipient_access=regexp:/etc/postfix/esa ... with esa containing: # Send non-local mail to the ESA /\@local1\.edu$/ dunno /\@local2\.edu$/ dunno // FILTER smtp:[esa]:25 As documented: * The same content filter is applied to all the recipients of a given message. Per-recipient content filter is supported with TWO postfix instances as described in MULTI_INSTANCE_README. Use per-recipient transport_maps entries in the Postfix instance before the content filter. Wietse
forward the bounce message to Reply-To
Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. I'd like to forward that bounce to whatever address is in the Reply-To field of the original message. This should apply only to bounces delivered to this particular inbox. Sounds like a procmail job, but if it's doable in Postfix alone I'd like to take that route since it's less resource-intensive. -- Florin Andrei http://florin.myip.org/
Re: Filtering on a per-recipient domain basis
On 2/26/2013 2:42 PM, Rich Bishop wrote: I'm running postfix 2.3.3 on Linux. I'd like to send mail to an external content filter based on the recipient address, which would be injected back into postfix on port 10027. This requires multiple postfix instances because the transport_maps parameter is global. http://www.postfix.org/MULTI_INSTANCE_README.html In the main/default postfix instance, use a transport_maps entry for each recipient that should be filtered, pointing to the filter next-hop. Allow unfiltered recipients to be delivered normally, no special arrangements should be needed for them (other than normal postfix configuration for your usage). The content filter should reinject to the second postfix instance, which should then deliver normally; basically a duplicate of the default instance but without the per-recipient transport_maps. Note that per-recipient transport_maps can be a bottleneck if your server is near its performance limits. A higher performance solution is to use virtual_alias_maps to rewrite the filtered recipients to a new domain eg. u...@example.com u...@filter.example.com and use transport_maps to direct filter.example.com to the filter entry port. This also requires a second postfix instance for reinjection and delivery of the filtered mail (well, not required, but very strongly recommended). If necessary, the recipient can be rewritten back to the original domain name in the second postfix instance. -- Noel Jones
Re: forward the bounce message to Reply-To
Am 26.02.2013 22:00, schrieb Florin Andrei: Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. I'd like to forward that bounce to whatever address is in the Reply-To field of the original message. This should apply only to bounces delivered to this particular inbox. Sounds like a procmail job, but if it's doable in Postfix alone I'd like to take that route since it's less resource-intensive. NO, NO AND NO SMTP works with envelopes and not with headers and there are a million reasons to do this - if i send a message with a reply-to header i expect that i get answers from HUMAN persons on this address and not bounces if whatever server sends me bounces to the reply-to-address i consider this server simply as broken example: * web-application * html form * you enter your email * the app sends the message to the woner with reply-to * NEVER EVER the mailserver is allowed to send bounces to the reply-to in errors-cases because you need only ONE bad guy smelling this which fills in random addresses to flood them with bounces don't do break SMTP careless - never! signature.asc Description: OpenPGP digital signature
Re: forward the bounce message to Reply-To
On 02/26/2013 01:07 PM, Reindl Harald wrote: NO, NO AND NO SMTP works with envelopes and not with headers and there are a million reasons to do this - if i send a message with a reply-to header i expect that i get answers from HUMAN persons on this address and not bounces if whatever server sends me bounces to the reply-to-address i consider this server simply as broken Hold on a second. This is not general-purpose email, it's automatically generated business stuff, normally not intended for human consumption. Twisting the rules here a little bit would save a lot of effort in different parts of the code. I do not intend to mess with regular email. No regular email is being sent through these machines. -- Florin Andrei http://florin.myip.org/
Re: forward the bounce message to Reply-To
Am 26.02.2013 22:17, schrieb Florin Andrei: On 02/26/2013 01:07 PM, Reindl Harald wrote: NO, NO AND NO SMTP works with envelopes and not with headers and there are a million reasons to do this - if i send a message with a reply-to header i expect that i get answers from HUMAN persons on this address and not bounces if whatever server sends me bounces to the reply-to-address i consider this server simply as broken Hold on a second. This is not general-purpose email, it's automatically generated business stuff, normally not intended for human consumption. Twisting the rules here a little bit would save a lot of effort in different parts of the code. so what set the envelope to whatever RCPT which sould reveive bounces and use From/Reply-To for anything not SMTP relevant and you are done - no single need to mangle anything * the RCPT does not see the envelope-sender in his client * he replies to the address in the From or Reply-To * bounces are going to the envelope as SMTP specifies it signature.asc Description: OpenPGP digital signature
Re: forward the bounce message to Reply-To
Florin Andrei: Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. No. It is sent to the SMTP envelope sender as required by RFC 5321. To send bounces elsewhere use the proper envelope address. One option is to use VERP (per-recipient return address). Wietse
Re: forward the bounce message to Reply-To
On 02/26/2013 01:48 PM, Wietse Venema wrote: Florin Andrei: Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. No. It is sent to the SMTP envelope sender as required by RFC 5321. To send bounces elsewhere use the proper envelope address. One option is to use VERP (per-recipient return address). Right, and the envelope sender matches the local inbox, which is why the bounce is sent there after all. *After* that, I want the bounce forwarded to the Reply-To address(es). -- Florin Andrei http://florin.myip.org/
Re: forward the bounce message to Reply-To
Am 27.02.2013 00:10, schrieb Florin Andrei: On 02/26/2013 01:48 PM, Wietse Venema wrote: Florin Andrei: Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. No. It is sent to the SMTP envelope sender as required by RFC 5321. To send bounces elsewhere use the proper envelope address. One option is to use VERP (per-recipient return address). Right, and the envelope sender matches the local inbox, which is why the bounce is sent there after all. *After* that, I want the bounce forwarded to the Reply-To address(es) and why do you not change the envelope in the application which is generating the messages instead try to violate RCF's which will not be supported on this list? signature.asc Description: OpenPGP digital signature
Re: forward the bounce message to Reply-To
Florin Andrei: On 02/26/2013 01:48 PM, Wietse Venema wrote: Florin Andrei: Sending out messages through a Postfix server. Delivery is refused for whatever reason (e.g. recipient does not exist), and then a bounce is sent by Postfix to a local inbox on that server, as a failure notification. No. It is sent to the SMTP envelope sender as required by RFC 5321. To send bounces elsewhere use the proper envelope address. One option is to use VERP (per-recipient return address). Right, and the envelope sender matches the local inbox, which is why the bounce is sent there after all. *After* that, I want the bounce forwarded to the Reply-To address(es). If you set the proper envelope sender address (VERP or otherwise), then you don't have to muck with Reply-To. Wietse
Re: Running namecache service on postfix server?
On Feb 26, 2013, at 11.51, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. why must the nameserver be local? i gather the point is to be able to trust the dns responses, which of course goes without saying - but there are methods for accomplishing this in scenarios with a non local nameserver, aren't there? i think rfc 6698 speaks to this briefly? -ben
Re: Running namecache service on postfix server?
On 02/26/2013 08:57 PM, b...@bitrate.net wrote: On Feb 26, 2013, at 11.51, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote: I have recently updated my DNS server and am observing the traffic from my mail server to constantly query for names. Some of these names are frequent requests, for example: zen.spamhaus.org. So I was thinking that I could benefit from running a namecaching setup on my mail server platform. This would cut down on traffic and time on my mail server. Is this a practice that is common? Are there any downsizes to doing this? When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. why must the nameserver be local? i gather the point is to be able to trust the dns responses, which of course goes without saying - but there are methods for accomplishing this in scenarios with a non local nameserver, aren't there? i think rfc 6698 speaks to this briefly? I don't think there is a MUST there in the IETF tradition. More of a SHOULD; I think it is a matter of performance, and perhaps security (I would have to net it out; definitely less 'room' for a MITM). I suspect people with experience in this area (mine is elsewhere in the IETF and IEEE 802) can well list the advantages of 'co-location'.
Re: Running namecache service on postfix server?
On Tue, Feb 26, 2013 at 08:57:51PM -0500, b...@bitrate.net wrote: When Postfix support for DANE (RFC 6698) is introduced, there will be a requirement to operate a local nameserver that is DNSSEC aware on any machine that wants to take advantage of peer certificate details published via DNSSEC to scalably deliver verified TLS email to many sites without the overhead of local per-site configuration. Why must the nameserver be local? Very easy. If the server is *not* local, you should not trust the AD-bit in its responses without authenticating the nameserver via something like TSIG. I am not going to bloat Postfix with TSIG support, this would be really silly, when a local cache can take care of that. A fortiori I am not going to bloat Postfix with its own RRSIG-validing DNSSEC support. Therefore, Postfix support for DANE will be sensibly predicated on a *local* DNSSEC verifying cache. Unless we add code to check that the resolv.conf in fact only contains local servers (I am disinclined to do that also), you will be able to break the warranty and trust the AD-bit from non-local nameservers by telling Postfix to enable DANE even with a resolv.conf that points to remote servers. If you do that, you only have yourself to blame when lack of TSIG, ... makes it possible to MITM your server's ostensibly secure email deliveries. All, I can say (and will say in the documentation) is that you've been warned. Since the fields of _res other than _res.options are not generally documented, there is no reasonable way to perform a run-time check that the configured nameservers consist of just 127.0.0.1 and/or ::1. So the plan is to document the warning clearly in all the relevant documents, and leave the rest to the administrator's ability to restrain himself from folly. Perhaps postfix check could generate a warning if DANE is enabled and non-local nameservers are found in /etc/resolv.conf (or and/or its chroot-jail version). -- Viktor.
