Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, lately I have been getting lots of spams ( who doesn't these days? ), and I noticed that these spams are easy to detect, since from the following header information, you can see the sender's address is a fake one:
So I am thinking to REJECT such spams from postfix. The rule would be simple:
extract sender's actual sending domain and claimed domain from Message-ID field and From field, and compare them. Normally these two should be same ( is it true? ). Otherwise, reject.
However, I am not an expert in postfix. Anyone could help how to configure postfix to do this task efficiently?
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
You could change things to this for some good spam blocking. I also rearranged it a bit so it's easier to read and flows better.
Code:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
reject_invalid_hostname (rejects helo with invalid characters like !, $, etc.)
reject_non_fqdn_hostname (reject helo that is not in domain.com format)
smtpd_sender_restrictions =
hash:/etc/postfix/access
reject_non_fqdn_sender (reject email address not in user@domain.com format)
reject_uknown_sender_domain (reject mail domain.com if domain.com does not exist)
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient (reject mail to users that don't exist)
smtpd_data_restrictions =
reject_unauth_pipelining (stops bulk mail senders)
strict_rfc821_envelopes = no
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
I work for an ISP with about 40,000 users and we use these settings and more. We get very few false positives because of these settings.
The way it checks the reject_unknown_sender_domain is by seeing if the domain has an A or MX DNS record. The only reason the from domain wouldn't have one of those records is if they're spoofing.
Thanks a lot. I will change accordingly and see how that works.
A few more questions:
1) Any changes in other postfix files?
2) How to log postfix actions so that I can see if it works properly for a few days?
3) Instead of reject right away, how to set up postfix so that it puts those deemed spams to another folder for later inspection?
( I am trying to be very cautious. )
4)
Code:
smtpd_helo_required = yes
will this cause my domain on black list of other domains since I probe too much? What is your experience?
Thanks again.
Quote:
Originally Posted by Child of Wonder
You could change things to this for some good spam blocking. I also rearranged it a bit so it's easier to read and flows better.
Code:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
reject_invalid_hostname (rejects helo with invalid characters like !, $, etc.)
reject_non_fqdn_hostname (reject helo that is not in domain.com format)
smtpd_sender_restrictions =
hash:/etc/postfix/access
reject_non_fqdn_sender (reject email address not in user@domain.com format)
reject_uknown_sender_domain (reject mail domain.com if domain.com does not exist)
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_unlisted_recipient (reject mail to users that don't exist)
smtpd_data_restrictions =
reject_unauth_pipelining (stops bulk mail senders)
strict_rfc821_envelopes = no
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
I work for an ISP with about 40,000 users and we use these settings and more. We get very few false positives because of these settings.
The way it checks the reject_unknown_sender_domain is by seeing if the domain has an A or MX DNS record. The only reason the from domain wouldn't have one of those records is if they're spoofing.
1. Main.cf is the only file you need to change for now. If you want to do more advanced configurations of Postfix you might need to create/change other ones.
2. Postfix should automatically log to /var/log/mail.log. Depending on how your syslog is set up, you should have a few days of logs in there.
3. Postfix can't move files based on whether it thinks they're spam. You'd need a filter like procmail to do that. You could simply set up the rules and then place warn_if_reject right in front of them to have Postfix not actually reject email that would hit these new rules, but only place a warning in your log file so you can see what mail would have been rejected.
For example:
Code:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
warn_if_reject reject_invalid_hostname
warn_if_reject reject_non_fqdn_hostname
smtpd_sender_restrictions =
hash:/etc/postfix/access
warn_if_reject reject_non_fqdn_sender
warn_if_reject reject_uknown_sender_domain
smtpd_recipient_restrictions =
permit_mynetworks
warn_if_reject reject_unauth_destination
warn_if_reject reject_unlisted_recipient
smtpd_data_restrictions =
warn_if_reject reject_unauth_pipelining
strict_rfc821_envelopes = no
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
4. No, all that command does is reject mail from servers that do not issue a HELO command, which is required by RFC standards. All properly configured mail servers should give a HELO command.
1. Main.cf is the only file you need to change for now. If you want to do more advanced configurations of Postfix you might need to create/change other ones.
2. Postfix should automatically log to /var/log/mail.log. Depending on how your syslog is set up, you should have a few days of logs in there.
3. Postfix can't move files based on whether it thinks they're spam. You'd need a filter like procmail to do that. You could simply set up the rules and then place warn_if_reject right in front of them to have Postfix not actually reject email that would hit these new rules, but only place a warning in your log file so you can see what mail would have been rejected.
For example:
Code:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
warn_if_reject reject_invalid_hostname
warn_if_reject reject_non_fqdn_hostname
smtpd_sender_restrictions =
hash:/etc/postfix/access
warn_if_reject reject_non_fqdn_sender
warn_if_reject reject_uknown_sender_domain
smtpd_recipient_restrictions =
permit_mynetworks
warn_if_reject reject_unauth_destination
warn_if_reject reject_unlisted_recipient
smtpd_data_restrictions =
warn_if_reject reject_unauth_pipelining
strict_rfc821_envelopes = no
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
4. No, all that command does is reject mail from servers that do not issue a HELO command, which is required by RFC standards. All properly configured mail servers should give a HELO command.
Hi, I just tested by sending an email bwteen my accounts on differnt domains, but got following error:
postfix/smtpd[27154]: warning: unknown smtpd restriction: "reject_uknown_sender_domain"
postfix/smtpd[27154]: NOQUEUE: reject: RCPT from destination.domain: 451 Server configuration error; from=<me@origin> to=<me@destination> proto=ESMTP helo=<destination_mail_server>
How to fix it? Thanks.
Quote:
Originally Posted by Child of Wonder
1. Main.cf is the only file you need to change for now. If you want to do more advanced configurations of Postfix you might need to create/change other ones.
2. Postfix should automatically log to /var/log/mail.log. Depending on how your syslog is set up, you should have a few days of logs in there.
3. Postfix can't move files based on whether it thinks they're spam. You'd need a filter like procmail to do that. You could simply set up the rules and then place warn_if_reject right in front of them to have Postfix not actually reject email that would hit these new rules, but only place a warning in your log file so you can see what mail would have been rejected.
For example:
Code:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
warn_if_reject reject_invalid_hostname
warn_if_reject reject_non_fqdn_hostname
smtpd_sender_restrictions =
hash:/etc/postfix/access
warn_if_reject reject_non_fqdn_sender
warn_if_reject reject_uknown_sender_domain
smtpd_recipient_restrictions =
permit_mynetworks
warn_if_reject reject_unauth_destination
warn_if_reject reject_unlisted_recipient
smtpd_data_restrictions =
warn_if_reject reject_unauth_pipelining
strict_rfc821_envelopes = no
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
4. No, all that command does is reject mail from servers that do not issue a HELO command, which is required by RFC standards. All properly configured mail servers should give a HELO command.
Now here came a real test. I got another spam, and here are related header information:
Code:
Return-Path: <rymub@xbeyond.fsnet.co.uk>
Received: from c-67-172-119-93.hsd1.ca.comcast.net (c-67-172-119-93.hsd1.ca.comcast.net
[67.172.119.93])
Received: from [67.172.105.180] (helo=qtp)
by c-67-172-119-93.hsd1.ca.comcast.net with smtp (Exim 4.43)
id 1GEFaX-0003IA-V2; Fri, 18 Aug 2006 18:25:25 -0700
Message-ID: <001f01c6c32d$aa82c87e$b469ac43@qtp>
From: "Eveline Richards" <rymub@xbeyond.fsnet.co.uk>
To me it is obvious the sender address is a fake one, since it is very different from the comcast cable used.
When postfix checks the sender's address, how does it know the sender's address is a known (maybe valid instead) address? And how to catech this type of spams? Probably back to my original questions?
Thanks.
Quote:
Originally Posted by Child of Wonder
My mistake... it's a spelling error. Left out an "n" in unknown.
A sender address can be spoofed very easily. Postfix has no way of knowing whether the email address the sender provides is a real email address or not. All Postfix can do is check to see if the domain.com portion of the email address exists using the reject_unknown_sender_domain rule and, in this case, this domain does exist and has an MX record so it passes that check.
Code:
dig mx xbeyond.fsnet.co.uk
; <<>> DiG 9.3.2 <<>> mx xbeyond.fsnet.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63745
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;xbeyond.fsnet.co.uk. IN MX
;; ANSWER SECTION:
xbeyond.fsnet.co.uk. 86400 IN MX 2 mail-in.freeserve.com.
;; AUTHORITY SECTION:
fsnet.co.uk. 28800 IN NS pridns1.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns2.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns3.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns4.svr.pol.co.uk.
;; ADDITIONAL SECTION:
pridns1.svr.pol.co.uk. 14058 IN A 195.92.193.4
pridns2.svr.pol.co.uk. 14058 IN A 195.92.195.161
pridns3.svr.pol.co.uk. 14058 IN A 195.92.67.18
pridns4.svr.pol.co.uk. 14058 IN A 195.92.168.157
;; Query time: 138 msec
;; SERVER: 192.168.0.250#53(192.168.0.250)
;; WHEN: Fri Aug 18 22:17:23 2006
;; MSG SIZE rcvd: 234
For my SPAM, and I get lots of it, I use a combination of spamassassin and sieve. All the messages identified as SPAM go from my Inbox to my SPAM mailbox automatically. A couple of times per week I check my SPAM folder to see if there are any false/positives. If I do get a repeating false/negative then I use SPAMCop to report it.
Is there anyway for postfix to check the sender's domain against the sending address, i.e., the IP in the received from field? Since as you said, a sender's address can be spoofed easily, while the sending address is not unless the ISP is collaborating.
Quote:
Originally Posted by Child of Wonder
A sender address can be spoofed very easily. Postfix has no way of knowing whether the email address the sender provides is a real email address or not. All Postfix can do is check to see if the domain.com portion of the email address exists using the reject_unknown_sender_domain rule and, in this case, this domain does exist and has an MX record so it passes that check.
Code:
dig mx xbeyond.fsnet.co.uk
; <<>> DiG 9.3.2 <<>> mx xbeyond.fsnet.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63745
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;xbeyond.fsnet.co.uk. IN MX
;; ANSWER SECTION:
xbeyond.fsnet.co.uk. 86400 IN MX 2 mail-in.freeserve.com.
;; AUTHORITY SECTION:
fsnet.co.uk. 28800 IN NS pridns1.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns2.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns3.svr.pol.co.uk.
fsnet.co.uk. 28800 IN NS pridns4.svr.pol.co.uk.
;; ADDITIONAL SECTION:
pridns1.svr.pol.co.uk. 14058 IN A 195.92.193.4
pridns2.svr.pol.co.uk. 14058 IN A 195.92.195.161
pridns3.svr.pol.co.uk. 14058 IN A 195.92.67.18
pridns4.svr.pol.co.uk. 14058 IN A 195.92.168.157
;; Query time: 138 msec
;; SERVER: 192.168.0.250#53(192.168.0.250)
;; WHEN: Fri Aug 18 22:17:23 2006
;; MSG SIZE rcvd: 234
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.