Japanese

top report presentation (PDF) article (Ja.) white list black list watch tool applyers Q&A blog (Ja.) links history contact

Q&A

Last update:  Oct 27, 2014
Publication:  Jun 10, 2007

1. Concept

Q1-1.  Does the S25R system exclude legitimate mail servers which don't have a reverse name?
A1-1.  No. S25R system administrators will accept them by whitelisting when finding retry accesses. The reason why the S25R system temporarily rejects hosts which don't have a reverse name is that they are end-user's computers with a strong probability.

Q1-2.  Does the S25R system exclude personal mail servers with a dynamic IP address?
A1-2.  No. S25R system administrators will accept them by whitelisting when finding retry accesses. However, mail servers with a dynamic IP address cause a risk of receiving spam or virus mail from end-user's computers with a reused IP address. I hope such mail servers send out mail through your ISP's mail server. Anyway, you need to do so if your ISP applies OP25B (Outbound Port 25 Blocking).

Q1-3.  Not a few legitimate mail servers have a reverse host name including plural separated numeral strings or a long numeral string. It is violent to reject such hosts, isn't it?
A1-3.  I don't think so. The reason why the S25R system temporarily rejects hosts which have a reverse host name including plural separated numeral strings or a long numeral string is that they are end-user's computers with a strong probability. S25R system administrators will accept legitimate mail servers by whitelisting when finding retry accesses.

Q1-4.  My mail server has a fixed IP address, but its reverse name is assigned by my ISP and is trapped by the S25R rules. I cannot change the reverse name. What shall I do to send mail to sites which apply the S25R system?
A1-4.  Don't worry. S25R system administrators will accept your mail server by whitelisting when finding retry accesses.
   I'm ready to announce your mail server's reverse name in the white list information page at your request. Please contact me.

Q1-5.  Deferring receiving mail by temporary rejection loads a mail sending server with the disk resource. It is rude to do that, isn't it?
A1-5.  I don't think so. Temporary rejection keeps mail on the disk of a mail sending server, but it doesn't damage the server. If anything, the S25R system reduces traffic load on the Internet relay lines by arresting transmission of message bodies of much spam.

Q1-6.  What is the difference from the DNSBL (Domain Name System-based Black List)?
A1-6.  DNSBLs list IP addresses with a past conviction for spam. A mail server which relies on a DNSBL may receive spam from end-user's computers infected by a bot if they don't have a past conviction for spam. Therefore, the spam block rate of a DNSBL is not so high as that of S25R. Meanwhile, the S25R system can block most of the spam from end-user's computers infected by a bot because it temporarily rejects hosts which seem to be an end-user's computer no matter whether they have a past confiction for spam or not. However, it requires the white list for permitting legitimate mail servers mistakenly rejected.
   By the way, also DNSBLs may cause false positives because they mistakenly or willfully list legitimate mail servers on occation. In order to avoid missing legitimate mail, you should make your mail server return the response code "450" (not "554" by default of Postfix) against hosts which are trapped by the DNSBL, and whitelist hosts which retry transfer (most of the spam accesses don't retry).



2. Operation

Q2-1.  How high is the false positive rate of the S25R system?
A2-1.  I don't have precise data, but the false positive rate before whitelisting is estimated to be about 13% in counting hosts which have sent me legitimate mail. It seems to be high, but it approaches zero as whitelisting proceeds.

Q2-2.  I would like to apply the S25R system, but I'm afraid that it might reject many legitimate mail servers because my site has many users. Is there anything to do to apply the S25R system safely?
A2-2.  Sure. First, install the published white list. After setting S25R, watch the mail log using my rejection log sorting script. If you find many blocked hosts which seem to be legitimate, cancel S25R and put them into the white list. While canceling S25R, legitimate mail is not missed, though spam is also received. After finishing whitelisting, set S25R again. Repeating this procedure until the white list becomes stable, you will be surely able to avoid missing legitimate mail.

Q2-3.  Can we automate whitelisting?
A2-3.  Yes, you can. Mr. SATOH Kiyoshi has published automatic whitelisting systems based on the S25R system. Rgrey greylists hosts which are trapped by the S25R rules and permits them automatically when they retry sending. Starpit defers a response (tarpitting) to hosts which are trapped by the S25R rules and permits them automatically when they are found patient. taRgrey uses both of tarpitting and greylisting. See the links in the links page or ask me.

Q2-4.  My mail server serves the SMTP authentication and the POP-before-SMTP authentication. Authenticated clients such as mobile PCs are rejected by the S25R rules. Can I solve this problem?
A2-4.  Yes, you can. In both of the smtpd_client_restrictions and smtpd_recipient_restrictions parameters, specify the permit_sasl_authenticated specification for the SMTP authentication, and the client authentication database for the POP-before-SMTP authentication, just after the permit_mynetworks specification. Here is an example when using DRAC as a POP-before-SMTP authentication server. "dracd" is the name of the database. Don't write ".db" even though the real file name is "dracd.db".

smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access hash:/etc/mail/dracd,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections

smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access hash:/etc/mail/dracd,
  reject_unauth_destination

Q2-5.  Can we reject mail addressed to unknown recipients and obviously illegitimate mail without prompting to retry sending before the client check by S25R?
A2-5.  Yes, you can. In the smtpd_client_restrictions parameter, you can insert the following bold lines just before the check_client_access specification.
   The check_helo_access specification rejects illegal HELO addresses (see the sample of the /etc/postfix/helo_restrictions file in Appendix A. in the report). The reject_unauth_destination specification rejects third-party relay. The reject_unlisted_recipient specification rejects mail addressed to unknown recipients (in case this mail server can detect the "user unknown" error).
   This configuration makes my rejection log sorting script display rejection records excluding those of mail accesses addressed to unknown recipients and obviously illegitimate mail accesses. It will help you to watch the log easily for whitelisting.

smtpd_client_restrictions =
  permit_mynetworks,
  check_helo_access regexp:/etc/postfix/helo_restrictions,
  reject_unauth_destination,
  reject_unlisted_recipient,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections

Q2-6.  Is it effective to use a DNSBL together with S25R?
A2-6.  Yes, it is. I have found SpamCop rather useful. Once I got a 99.5% block rate using SpamCop together with S25R, when the block rate by only S25R was 99.2%. However, you should make your mail server return the response code "450" against hosts which are trapped by the DNSBL, because DNSBLs may cause false positives. In the /etc/postfix/main.cf file, add the following bold lines.

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections,
  reject_rbl_client bl.spamcop.net

   My rejection log sorting script can display records of the rejections by DNSBL too.
top report presentation (PDF) article (Ja.) white list black list watch tool applyers Q&A blog (Ja.) links history contact