Located at /etc/tcprules.d/, tcp.smtp is a 2 line (default toaster) file that orchestrates many of the QMT functions. It is the traffic cop in a busy intersection, controlling SMTP processing alternatives.
If you're running another MTA in concert with QmailToaster, or you have an unusual or complicated setup, the following might not be applicable to you. If that is the case, you should take your problem straight to the mailing list. Hopefully this page will eventually cover advanced configurations as documented by those who have such requirements.
Disclaimer: I do not have a working domainkey setup, so DK settings are provided as a best guess. For proper domainkey setup, see Domainkeys. Also, this is a work in progress. Be sure to check back for improvements, and make corrections as you find errata.
Reminder: if you make changes to tcp.smtp, execute the following afterwards to activate the changes:
# qmailctl cdb
You do not need to stop and start qmail when only regenerating the .cdb files.
Stock (default) tcp.smtp file Your default tcp.smtp file on a fresh install looks like this (backslashes are for display purposes only, do not include them or newlines or extra spaces in the file - there are two and only two lines here):
127.:allow,RELAYCLIENT="",DKSIGN="/var/qmail/control/domainkeys/%/private" :allow,BADMIMETYPE="",BADLOADERTYPE="M",\ CHKUSER_RCPTLIMIT="15",CHKUSER_WRONGRCPTLIMIT="3",\ DKVERIFY="DEGIJKfh",QMAILQUEUE="/var/qmail/bin/simscan",\ DKQUEUE="/var/qmail/bin/qmail-queue.orig",\ DKSIGN="/var/qmail/control/domainkeys/%/private"
You should read it like this:
line 2) (readability is imperfect (aka sucks). This is one long mother of a line. Again, ignore the '\' and newline)
:allow,BADMIMETYPE="",BADLOADERTYPE="M",\ CHKUSER_RCPTLIMIT="15",CHKUSER_WRONGRCPTLIMIT="3",\ DKVERIFY="DEGIJKfh",QMAILQUEUE="/var/qmail/bin/simscan",\ DKQUEUE="/var/qmail/bin/qmail-queue.orig",\ DKSIGN="/var/qmail/control/domainkeys/%/private"
Let's break that down. Entries in the default tcp.smtp and what they mean:
127. ->local (as in 127.0.0.1)
: ->if, then or 'default follows'
allow ->instruction to allow,
RELAYCLIENT="" ->variable set to null, calls smtp-auth, never seen it written any other way
DKSIGN="/var/qmail/control/domainkeys/%/private" ->domain key processing instructions to sign mail with dk
Putting it all together: if the incoming mail is local (127.) then allow relay process by variable (smtp-auth) and sign the message with the domain key info.
: ->if, then--since it is empty(nothing to the left) all mail not meeting the line 1) conditional is processed by the following rules which are the default. allow ->instruction to allow BADMIMETYPE="" ->warlord patch variable--it's fine as-is BADLOADERTYPE="M" ->warlord patch variable--it's fine as-is CHKUSER_RCPTLIMIT="15" -> set max # of recipients, more than this set number, the toaster treats it as a 'mail-bomb-event' and denies further delivery attempts CHKUSER_WRONGRCPTLIMIT="3" -> set max # of non-existant users, once this number is met, the toaster treats it as a 'mail-bomb-event' and denies further delivery attempts DKVERIFY="DEGIJKfh" ->instructions by which to verify domain keys QMAILQUEUE="/var/qmail/bin/simscan" ->instuction how and where to run it through simscan (thus spam/clam/attach) before delivery DKQUEUE="/var/qmail/bin/qmail-queue.orig" ->instruction for where to queue messages for domain key verification. DKSIGN="/var/qmail/control/domainkeys/%/private" ->instruction for location for domain key verification of private key.
Putting it all together: Mail making it this far (line 2 of 2) is not local therefore from a remote server, so process it this way as default handling: check for bad mimetypes check for badloader types check for max recipients check for incorrect addressees pull dk signing info if applicable send it through simscan (and it's buddies) finish dk verification then deliver to the recipient. Wow, that is a lot to master.
Now let's talk about customizations. The default install is very good with very sane defaults for setting up a standalone mail server,
which explains the popularity with not-so-experienced admins such as myself. Easy to setup, secure by design, secure on setup, wonderfully protective of your valuable emails. You really want to mess with that? Please keep an accurate record of your customizations for your sanity. The more you customize, the more "on your own" you go.
I don't have domainkeys setup for [insert reason here]
Make a copy of tcp.smtp to something like tcp.smtp.dk, in case you change your mind later, then edit out any reference to domainkeys in the tcp.smtp file, then execute: #qmailctl cdb
Warning: no domainkey=Yahoo!/bulk (and possibly other sites) Your mail will go straight to the bulk folder, unless the recipient 'whitelists' your sender by adding to the contacts list.
I am confused about badmimetypes/badloaders and simscan...they overlap
Well, they differ in that simscan uses ripmime to check against file extensions only, whereas badmimetypes/badloaders checks against "known"(to somebody) mime signatures. The difference is subtle, yet they both block attachments and notify the sender. If you feel compelled to remove badmimetypes/badloaders from your simscan regimen, then copy the tcp.smtp file to something like tcp.smtp.blbm, in case you change your mind later, then edit out any reference to badloaders and badmimetypes in the tcp.smtp file, then execute: #qmailctl cdb (alternatively: you could leave tcp.smtp alone and comment out all lines in these 2 files and execute: #qmailctrl cdb)
I want to scan even local mails (clam, spam, attach) as a further protection for my windows users. You know, to keep them from infecting each other.
Add (,QMAILQUEUE="/var/qmail/bin/simscan") without parentheses() to the end of line 1). Execute: #qmailctl cdb
Now mail from user1-at-domain3-dot-com will process through simscan before it is delivered to user2-at-domain3-dot-com. Also, mail from user1-at-domain3-dot-com will process through simscan before it is delivered to user3-at-domain2-dot-com on the same toaster. Interestingly, simscan will scan that message for attachments and viruses, though not for spam. I believe that has something to do with the RELAYCLIENT variable or the 127 conditional. This is not something you should worry too much about. If you suspect you are harboring a spammer or a zombie on your domain, pull the plug on the account.
...to be re-formatted and continued.