On 2012-06-14 Giuseppe Perna wrote: > I allow relaying only to the hosts declared in main.cf file and users > are in the file / etc / passwd. postmaster is the user in this file. I > can confidently change the password or disable the user postmaster? > I'm not going to cause damage to the Postfix configuration?
The postmaster address is a role address (see RFC 2142) and should not be a mailbox (and thus not have a login) in the first place. It's common practice to alias that address to one or more user mailboxes. Changing the IMAP password to a postmaster mailbox will not change anything about mail routing in Postfix. Postfix is not an IMAP server and will thus not be affected by changes to your IMAP configuration. It's also unwise to make all local user accounts valid mail recipients. Better set local_recipient_maps = $alias_maps in main.cf and explicitly specify which local account has a mailbox associated with it. > these doors open. > > 22/tcp open ssh > 25/tcp open smtp > 37/tcp open time > 80/tcp open http > 110/tcp open pop3 > 113/tcp open auth > 125/tcp open locus-map > 143/tcp open imap > 443/tcp open https The open ports of your server are unlikely to help with identifying the problem. [...] > this is my configuration: > #postconf -n [...] > mydestination = $mydomain,esempio.it (local domain) I may be wrong, but I don't believe $mydestination should contain something like " (local domain)". [...] > relay_domains = $mydestination This is wrong. $relay_domains MUST NOT contain $mydestination. See <http://www.postfix.org/ADDRESS_CLASS_README.html> for more details. Also, your postconf output didn't show $smtpd_*_restrictions, so your server is running on default values in this respect: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination This means that your Postfix doesn't allow user authentication in the first place, so it accepts mail only from pickup and $mynetworks. That said, your log excerpt does not provide sufficinet information to determine how exactly the suspected spam entered your server. Find the queue ID of such an e-mail (e.g. 23094B81BD7) and run the command grep QUEUE_ID /var/log/mail.log replacing QUEUE_ID with the actual queue ID (and /var/log/mail.log with the path to your actual mail log). Also make sure that the lines are not truncated like they were in the log snippet from your first mail. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky