Postfix reject mail to mail@mydomain.com
I'm a postfix / dovecot newbie with a few domains and a few users, so I have not set up virtual user mappings or SMTP Auth yet.
Say I have mydomain.com. There is a user "mail" in the /var/mail folder that gets filled up with junk mail apparently sent to a real user account and cc'd to "
1. Is this an important error mail address that I should allow mail to be sent to from within my own host?
2. It seems I can reject spam to mail@anyofmydomains with a postfix regexp. Would this work?
in /etc/postfix/regexes:
/^mail@/ REJECT
in main.cf:
header_checks=
regexp:/etc/postfix/regexes
3. Would this fail if the mail is sent as follows?
To: "Dodo" <
4. Separate question. I saw on the net a sample /var/log/mail.log output showing a line saying "pipe … (dovecot)" where postfix hands mail off to dovecot. But in my setup that is not logged. Dovecot just slurps from /var/mail/. Any problem with this?
5. Mostly I am worried I do not want to:
1) get tagged as an open relay by accident even though I haven't installed SMTP Auth.
2) use lots of cpu/memory for postfix / dovecot / spamassassin.
3 Replies
2. No, as you have it that won't work; header_checks processes the name of the header as well as the value. You'd want a regex like /^Cc: mail@/ instead of /^mail@/. Also, please don't REJECT mail you know is spam - use DISCARD instead. Using REJECT will mean that the mail server which tried to deliver the mail to you will create a bounce message to the email address listed as the Return-Path (which is normally some innocent person who's not involved) and send it there. DISCARD creates the illusion that your server accepts the mail, but in reality it just drops it on the floor.
3. Yes, that sort of syntax would cause the above to fail. However, because you're using regexes you can use something like /^Cc: (.*<)?mail@/ to catch both. (disclaimer: I've never used regexes in postfix and the above was written using a Perl-style regex; you may need to escape the parenthesis, asterisk and/or the question mark in order for it to work.)
4. Well, there are two ways to pass email to a POP3 server. One, which is the way you currently have it set up, is that the SMTP saves it locally itself and the POP server picks it up from there. An alternate way is to have the SMTP server hand the mail to the POP server and let it decide where it wants the mail kept. I've only ever done things the first way so I'm not sure how the second way would be done; however, AFAIK, both are equally valid ways of doing this.
5.
1) Open relays are servers that accept mail to any domain and deliver them. If you can connect to your SMTP server as an unauthenticated user and use it to send mail to a completely uninvolved domain, then your server is an open relay and should be fixed. However, it's fine for any user to connect to your server and use it to send mail for domains which you explicitly set up; in fact, using SMTP Auth for such would mean you wouldn't get any mail at all.
Equally, your server is not an open relay if SMTP Auth is required for a user to send mail to any domain.
2) That I'm afraid I can't advise much on. I've heard that SpamAssassin is a resource hog but have never used it myself so can't really expand on that. Plus, everything I read about it being a resource hog was back when Linode was using UML; the story may be different now on Xen.
@Sophira:
2. No, as you have it that won't work; header_checks processes the name of the header as well as the value. You'd want a regex like /^Cc: mail@/ instead of /^mail@/. Also, please don't REJECT mail you know is spam - use DISCARD instead. Using REJECT will mean that the mail server which tried to deliver the mail to you will create a bounce message to the email address listed as the Return-Path (which is normally some innocent person who's not involved) and send it there. DISCARD creates the illusion that your server accepts the mail, but in reality it just drops it on the floor.
While DISCARD is reasonable choice (except that makes the address look valid, which means you'll just get more spam on it), REJECT should NOT be creating bounce messages to innocent people. Those happen when you ACCEPT at SMTP time and then later reject it and create a bounce message, which is a terrible thing to do. (That is, it's okay to ACCEPT and then drop it as spam in post processing: just don't bounce it.)
@SteveG:
While DISCARD is reasonable choice (except that makes the address look valid, which means you'll just get more spam on it), REJECT should NOT be creating bounce messages to innocent people. Those happen when you ACCEPT at SMTP time and then later reject it and create a bounce message, which is a terrible thing to do. (That is, it's okay to ACCEPT and then drop it as spam in post processing: just don't bounce it.)
I didn't say that the Linode server would generate a bounce message. I said that whatever server tried to deliver it would generate a bounce message. In other words, it still generates bounces, it's just not you that's doing it.
(Of course, if the spammer is sending directly from their local box to your MX - which is increasingly common - no bounce messages would be created. But my point still stands for those who don't.)