On 12/30/2011 2:12 PM, /dev/rob0 wrote:
On Friday 30 December 2011 14:46:46 Lorens Kockum wrote:
On Fri, Dec 30, 2011 at 12:51:27PM -0600, Noel Jones wrote:
These are rejected and not useful to our discussion. Please
show ALL the postfix logging of a suspect transaction that
makes it to your queue. In particular, we want to see if
there is a sasl_username= line logged for a suspicious QUEUEID.
Stephen, you say that you have a lot of mail in the queue. I
suppose you use `mailq` to see that? You need to take the queue
ID of a suspect mail from there, grep /var/log/maillog for that,
and send us the output.
Specifically, we would be most interested in how the message first
entered the queue. Arrival via smtpd(8) means you (Stephen) have an
access maps problem, or, as Noel surmised, exploited SASL user
credentials. Arrival via pickup(8) means you have some other kind of
exploit, such as a compromised HTTP-PHP script.
I'll also take this opportunity to nitpick in some ways that Noel
spared you. :)
smtpd_recipient_restrictions = hash:/etc/postfix/access,
"access" is a terrible name for an access lookup, believe it or not!
And here you are using it as an implied check_recipient_access lookup,
which as Noel pointed out, should not be done. What is this lookup
doing? (Do you know?)
check_client_access hash:/etc/postfix/client_checks,
This one is named appropriately, but possibly not *used* in a safe,
reasonable manner. What is this one doing?
check_recipient_access hash:/etc/postfix/sender_checks,
check_sender_access hash:/etc/postfix/sender_checks,
Same file, named "sender_checks", being used for both sender and
recipient lookups? That might be reasonable, but "sender_checks" is
not a good name in that case.
In general, check_sender_access is not a good tool. Sure, it does
exactly what it claims to do, but most spam has forged sender
addresses. Therefore check_sender_access is reasonable neither for
whitelisting nor for blacklisting.
My bet is on this file; you have done something in "sender_checks"
that you should not have done.
So it turns out my replacement while I was on vacation modified my
main.cf. I went back to an back up I have a few weeks ago and changed
it back. Now I don't have that problem any more. What it came down to
was "check_relay_domains" had been removed for some reason.
While I'm no where near an expert on Postfix, usually the Ubuntu virtual
mail server guide is a pretty good place to start. That's what I used
to first set this server up years ago.
This is my current version of a postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
hash:/etc/postfix/majordomo/majoraliases
allow_untrusted_routing = no
bounce_queue_lifetime = 2h
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
debug_peer_level = 1
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
in_flow_delay = 5s
inet_interfaces = all
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 1d
message_size_limit = 26214400
mydestination = localhost.localdomain, localhost, mta1.rcr.inc
mta2.rcr.inc, ridelouise.com, canadiarockiessummer.com, rcr.west
rcr.inc
mydomain = skircr.com
myhostname = smtp.skircr.com
mynetworks = 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24,
192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/24, 192.168.7.0/24,
209.91.64.21, 127.0.0.0/8, 10.0.100.0/24, 10.0.6.0/24,
192.168.10.0/24, 192.168.80.0/23, 192.168.142.0/24,
216.133.52.45, 216.113.43.184, 192.168.143.0/24, 69.70.230.206,
207.96.243.24, 207.96.243.25, 24.37.1.234, 10.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
owner_request_special = no
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix-2.0.11/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_helo_name = skircr.com
smtpd_banner = $myhostname ESMTP $mail_name. We block/report all
spam/spammers.
smtpd_client_restrictions = permit_mynetworks
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit
smtpd_recipient_restrictions = check_relay_domains, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_invalid_hostname, reject_unauth_pipelining,
reject_non_fqdn_sender, reject_unknown_sender_domain,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_rbl_client zen.spamhaus.org, reject_rbl_client
combined.njabl.org, reject_rbl_client dbl.spamhaus.org,
check_policy_service inet:127.0.0.1:60000, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = hash:/etc/postfix/sender_restrictions,
permit_sasl_authenticated, permit_mynetworks,
reject_unauth_pipelining, permit
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt
smtpd_tls_key_file = /etc/ssl/private/smtpd.key
smtpd_tls_loglevel = 9
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf
virtual_gid_maps = static:119
virtual_mailbox_base = /usr/local/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains_maps.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_minimum_uid = 109
virtual_transport = virtual
virtual_uid_maps = static:109
--
Stephen Atkins
