TCPware FAQ: SMTP
Can I reject something based on its subject? For example: anything that has ILOVEYOU in the subject?
Yes, by using the :rfc822: reject rules. For exmaple: the following lines would reject all messages that have "ILOVEYOU" in the subject space:
! ! Reject anything with an RFC822 Subject header of ILOVEYOU ! cyberpromo.com or nowhere.com ! :Subject: ILOVEYOU
I don't see all the addresses a mail message was sent to when the message is forwarded from VMSmail. Why is that? Can I do something to have all the addresses included?
The problem is that a VMSmail account (for example, JDOE) has been set to forward mail to another address.
When a message is sent to the JDOE account via SMTP, it is forwarded to the address specified by the SET FORWARD command. When the message is delivered to that address, it lists only the JDOE recipient and the sender, but not other recipients.
The solution is to ensure that the headers parameter is set to send the header information.
The MAIL CONFIG utility includes a parameter called "Include Resent Headers on VMS MAIL forwards." If set to TRUE (the default), the SMTP server sends extra header information, including when the message was resent, who is was resent from, and who is was resent to. To access the utility, enter TCPWARE CONFIG/MAIL.
Some SMTP Servers, Microsoft Exchange, for example, do not handle those extra headers well and you cannot see the other addresses that the email was sent to.
Can TCPware be configured to have a return address of user@domain instead of user@host.domain?
When the ENVELOPE-FROM parameter is defined, the value is used for the host name instead of the actual host name sending MAIL FROM: line to the remote server. This is useful if there are multiple independent systems that send mail that you would like to appear to be a single system.
Can I redefine the location of TCPware SMTP spool directory?
Yes, though it is unsupported. You can edit smtp_control.com and change the following:
$! --- Create specific and common spool directories $! $ spool_common = "TCPWARE_COMMON:[TCPWARE.SPOOL]" $ spool_specific = "TCPWARE_SPECIFIC:[TCPWARE.SPOOL]" $ if f$parse(spool_common).eqs."" then - create/directory/protection=(S:RW,O:RW,G,W)/log 'spool_common' $ if f$parse(spool_specific).eqs."" then - create/directory/protection=(S:RW,O:RW,G,W)/log 'spool_specific' $! $! --- Define system logicals $! $ def TCPWARE_SMTP_WORK "''spool_specific'" $ def TCPWARE_SMTP_INCOMING_MAIL "''spool_specific'" $ def TCPWARE_SMTP_OUTGOING_MAIL "TCPWARE_ROOT:[TCPWARE.SPOOL]
To:
$! --- Create specific and common spool directories $! $ spool_common = "new_device:[new.directory]" $ spool_specific = "new_device:[new.directory]" $ if f$parse(spool_common).eqs."" then - create/directory/protection=(S:RW,O:RW,G,W)/log 'spool_common' $ if f$parse(spool_specific).eqs."" then - create/directory/protection=(S:RW,O:RW,G,W)/log 'spool_specific' $! $! --- Define system logicals $! $ def TCPWARE_SMTP_WORK "''spool_specific'" $ def TCPWARE_SMTP_INCOMING_MAIL "''spool_specific'" $ def TCPWARE_SMTP_OUTGOING_MAIL "new_device:[new.directory]
Remember that this is an unsupported change, which among other things means that upon an upgrade of TCPware, this modification (like all control file modifications) will not be preserved and will have to be re-implemented.
Can TCPware be configured to disable unauthorized mail relaying and SPAM, and how can I tell if my system allows unauthorized mail relaying?
Yes. You can configure the TCPWARE:SMTP_SERVER_REJECT. file to accomplish this. The following is an example SMTP_SERVER_REJECT. file that can be used as a starting point to create your own reject file. In the example, only mail that is from the 10.0.0, the 10.115.140, or the 10.115.141 subnets with a from address ending in flowers.com will be relayed. You can test to see if your system allows relaying of unauthorized messages by telneting to MAIL-ABUSE.ORG from the machine you are testing.
! ! This is a sample reject file for the company FLOWERS.COM. ! ! This file is processed sequentially. In other words, processing ends ! on the first rule that the message applies to. So if you have a ! wildcard accept at the top of this file, then no other rules will be ! processed. ! ! Entries can have one of the following formats: ! ! from_user [from_ip to_user action action-data] ! ! :rfc822 header ! ! Wildcards can be used in FROM_USER, FROM_IP, and TO_USER. ACTION is ! the reject action, which is one of: ! ! n Don't reject, but rewrite TO address to be ACTION-DATA. ! If ACTION-DATA is blank then we simply deliver to ! TO_USER. ! ! y Reject and use optional ACTION-FIELD as a rejection ! message format that can contain up to three %s ! formatting designators for mail from, mail to, and ! local domainname. ! ! q Reject quietly -- don't inform Sending SMTP Client that ! message will be discarded. If only FROM_USER is specified ! other fields default to FROM_IP=*, TO_USER=*, and ACTION=n. ! ! Don't rewrite or reject any mail to "postmaster*" ! * * postmaster* n ! ! ! Accept all messages with MAIL FROM:<> (bounce messages) ! This rule is commented out because you probably don't want it, ! although we're _supposed_ to always accept it. This is the main ! method relay attacks use, by always saying they are from <> to take ! advantage of that RFC hole. ! ! <> * * n ! ! Reject anything with a Message-ID that appears to have originated from ! cyberpromo.com or nowhere.com ! :Message-ID: <*@cyberpromo.com> :Message-ID: <*@nowhere.com> ! ! Reject mail from well-known SPAM sites with sample non-standard error ! messages. ! <*answerme.com> * * y "Spam from <%s> rejected" <*cyberpromo.com> * * y "Spam from <%s> to <%s> rejected" <*pleaseread.com> * * y "Spam rejected;%.0s%.0s Contact postmaster@%s" ! ! Disallow percent-hacks (e.g, joe%somewhere.com@flowers.com) ! * * *@*@*flowers.com y "No forwarding-path relaying allowed" ! ! Disallow "!" UUCP hacks (e.g. somewhere.com!joe@flowers.com) ! * * *!* y "No UUCP relaying allowed" ! ! Rewrite all mail to webmaster to the postmaster. ! * * webmaster@*flowers.com n postmaster@flowers.com ! ! ! Disallow relaying through our mailer, and only allow users on our ! networks to claim to be from our company (flowers.com) ! * * *@flowers.com n * * *@daisy.flowers.com n * * *@[10.0.0.1] n ! <*flowers.com> 10.0.0.* * n <*flowers.com> 10.115.140.* * n <*flowers.com> 10.115.141.* * n ! ! Allow our internal systems to bounce mail out. !
Can I set up an SMTP address that goes to multiple recipients?
Use SMTP aliases. TCPware's default configuration will use the file TCPWARE:SMTP_ALIASES. for SMTP aliases.
The following example shows how to set up SMTP aliases and SMTP mailing lists:
############################################### # # This is a sample file of SMTP aliases. # # Lines such as these starting with a "#" # are comments and are ignored by the parser. # # The syntax of an entry in this file is: # # alias: expansion; # # The expansion is a comma-separated list of # addresses in RFC821 form which may span # across multiple lines. The list is # terminated by the semicolon. # # To create a mailing list with the # addresses stored in a separate file, # the format is: # # listname:: list-owner, address-filespec; # # where "list-owner" is a valid address # which will be used as the # return-path for the mailing list message, # and "address-filespec" is a complete file # name for the file # containing the list of addresses. # # Alias expansion is recursive; when an # alias is expanded, further expansion # it attempted on each element of the # expansion. # ############################################## # example of simple mail forwarding... bigboote: bigboote@machine.com ; # example of a multi-destination alias... whorfin: bigboote, fin@hosts.com ; # example of a mailing list expansion... info:: bigboote, TCPWARE:file.text ;
My reply fails because the cc: address doesn’t include a domain name. Why does this happen?
There is no way to have TCPware append the domain name to the incomplete FROM or CC lines. The client should not be sending incomplete SMTP addresses.
You could use the SMTP_REJECT file to configure SMTP to not accept messages with incomplete recipients. Then when the client sends the bad messages they will be rejected and this will force the user to enter a valid mail address.
I have to configure SMTP on the system to send all messages out through our sites SMTP relay server, what do I have to do to configure TCPware to do this?
You have to set a FORWARDER and the FORWARD-REMOTE-MAIL to true in the mail configuration. You can do this with as follows:
$ TCPWARE CONFIGURE/MAIL SET FORWARDER name-of-forwarder SET FORWARD-REMOTE-MAIL TRUE EXIT $ @TCPWARE:START_SMTP