; MegaBrutal's SMTP Server (MgSMTP) ; Copyright (C) 2010-2015 MegaBrutal ; This is an example configuration file for MgSMTP. ; You may inspect it to learn about the configuration options of MgSMTP, and (if ; you find it convenient) you may copy and edit it to make your own configuration ; file. ; You should read readme.txt prior reading this file. ; The "Server" section contains some basic, general settings for your server. [Server] ; The "Name" key specifies the hostname as MgSMTP will identify itself. The server ; will report it in greetings, in HELO commands sent to other servers, in failure ; notices, and it'll accept e-mail addresses with the given hostname as local. ; It can be a virtual hostname (such as a No-IP domain pointed to your IP), it's ; not required to be the server's forward-confirmed reverse DNS. In any case, ; however, this hostname must be resolvable to your IP address. Moreover, you ; SHOULD specify your server's FCrDNS, if you can, and your server MUST have a ; valid FCrDNS in any case (even if it's not the one supplied as "Server\Name"). ; If you have a dynamic IP address, unfortunately you can't use your reverse hostname ; as your server's name because it changes too often, and your server name MUST ; always resolve to your actual IP, as mentioned above. ; The "Alias" key is optional. You may use it to specify other destination domains for ; your mail server. ; Here's one example: ;Name = example.org ;Alias = example.com,example.net ; According to the example above, this server will accept e-mails with recipient ; addresses such as foobar@example.org, foobar@example.com, and foobar@example.net ; as ones destinated to this server. All of the listed addresses will address the same ; mailbox: "foobar" - unless domain-specific mailbox support is enabled (see below). ; Another example: ;Name = mx.mycutedomain.com ;Alias = mycutedomain.com ; For example, you'd like to run a mail service for mycutedomain.com on the host named ; mx.mycutedomain.com. You need to add mx.mycutedomain.com as an MX record for ; mycutedomain.com. Name = ; "ListenPort" is a list of port numbers MgSMTP will listen on. More than one port ; numbers may be given, separated by commas. The standard (IANA-assigned) port for ; SMTP service is 25. ListenPort = 25 ; Use "TimeOffset" to set the timezone of your SMTP server. It is used to append ; corrections to "Date" headers. Note that MgSMTP only appends a "Date" header to an ; e-mail if it receives it without one present. ; Most e-mail clients use the correction to show the e-mail's send time correctly. ; Such corrections consist of 4 decimal digits, with the 2 more significant ones ; denoting the hours and the 2 least significant ones denoting the minutes of offset. ; This field is interpreted as an integer, so "200" and "+0200" do the same. ; For example, if the server's clock runs in the timezone GMT+2:00, set "+0200" for ; "TimeOffset". Negative numbers are also accepted, of course. ; The "TimeCorrection" key previously used for this purpose is now deprecated, but still ; interpreted if specified. If both "TimeCorrection" and "TimeOffset" keys are present, ; then "TimeCorrection" will be ignored. TimeOffset = +0000 ; The "Policies" switch enables or disables the enforcement of policy settings for ; your server. If this option is disabled, MgSMTP will ignore any settings ; specified under the "Policies" section, such as rule tables for hosts and users. ; All hosts will get all rights by default. I really don't recommend to disable ; "Policies", if your server is accessible from any untrusted network. If you ; let your server to operate on the Internet with this option disabled, your mail ; system will act as an open mail relay. Open relays are often used to broadcast SPAM, ; thus they often get blacklisted! ; Still, there is an option to disable policies, because it may be convenient for ; testing and use on trusted networks. Policies = On ; The "Mailbox" switch enables or disables local mailboxes on your mail server. ; If disabled, your server will never accept any e-mails those are addressed for ; this server. Mailbox = On ; The "Relay" switch enables or disables the server's willingness to relay e-mails. ; If you disable this option, your server in no circumstances will accept any ; e-mails those need to be relayed. Even from hosts those are set to have the right ; to relay by the policy settings. ; Note, previously queued e-mails will still be relayed; and DSNs to be relayed may ; still be generated internally. Relay = Off ; The "Log" switch enables or disables logging. Log = On ; The "Policies" section defines the policy settings for the server. Note, if you ; have disabled the "Policies" switch above, the settings below will be ignored. [Policies] ; If "ReqHELO" is enabled, the server won't process any commands sent by the client ; (except "AUTH") until it identifies itself with the "HELO" or "EHLO" command, as ; the RFC for SMTP recommends it. Since MgSMTP will only use the reverse DNS of a ; host (and its IP) to determine its rights, I don't think it's necessary to require ; a HELO. However, I've never seen any mail delivery systems or e-mail clients those ; don't start conversations with other systems with a HELO, so a client that doesn't ; do so might be considered suspicious. ReqHELO = Off ; If "HideVersion" is enabled, MgSMTP will not reveal its version number in its ; initial greeting. Though it will still report the fact that it's an "MgSMTP" ; instance, however; and it will still reveal its version number in Delivery Status ; Notification e-mails and in "Received" headers. HideVersion = Off ; "Users" enables or disables the user authentication feature. If disabled, the ; software ignores the "Policies\Users" section (see below) completely, and won't ; even report the AUTH feature in responses to EHLO commands. ; If you enable "Users" here, but don't define user accounts below, that will have ; the very same effect as you set "Off" here. Users = Off ; To prevent abuse, you can limit the number of AUTH attempts a client may make in ; one session. After "MaxAuthAttempts" number of failed AUTH negotiations, the client ; will get disconnected. Supply "0" if you don't want to limit AUTH attempts. ; Though the client is free to connect again to make further attempts, but at least it ; will stop some of those malicious bots. MaxAuthAttempts = 4 ; The "FCrDNSPolicy" key tells MgSMTP whether to verify if the reverse hostnames of ; connecting clients are forward-confirmed, and if so, how to handle the result. ; Forward-confirmed reverse DNS means, if you take an IP and resolve its reverse name, ; and then you resolve the IP for the resulting hostname, you get the original IP. This ; is the expected situation. But technically it is possible that the results of reverse ; and forward lookups are inconsistent. Basically, if you own a static IP, you may set ; any reverse hostname (PTR record) for it. Even obscure ones like "i.am.the.king" and ; stuff like that - actually it can be any string that the DNS protocol permits, it may ; not even forward resolve at all. ; The following values are permitted for "FCrDNSPolicy": ; Naive - don't verify reverse hostnames at all ; Aware - verify reverse hostnames, re-evaluate host rights by IP only if ; an inconsistency is found ; Mean - verify reverse hostnames, re-evaluate host rights by IP only if ; an inconsistency is found, but disallow to acquire additional rights ; Strict - verify reverse hostnames, disconnect the client if an inconsistency ; is found ; On LAN, you can go with "Naive". For DMZ hosts, the minimum you should set is "Aware". ; The difference between "Aware" and "Mean" is that the latter won't let the host to ; acquire rights those it wouldn't get if it had a forward-confirmed reverse hostname. ; For example, you banned a host by its hostname, but you didn't ban it by its IP, ; and the FCrDNS test fails on it. Then "Aware" would let the host in, because after ; all it will completely ignore the fact that you've banned the host by hostname, since ; that reverse name is invalid anyway. But "Mean" would take into account that you've ; banned the host by hostname, and it would see that the host would actually get more ; rights after the re-evaluation by IP only, and so it wouldn't let the host to get ; those additional rights. ; Use "Strict" if you wouldn't like to accept e-mails from hosts with invalid reverse ; hostnames at all. In this case, such hosts will get disconnected with a permanent ; failure SMTP reply code (554). Sadly there are legitimate mail servers out there ; those have invalid reverse hostnames, thus banning all of them can be too radical, ; you may lose legitimate e-mails by doing so. If you didn't understand anything of ; this section, read back later. ; Again, now in layman's terms: THIS IS A SECURITY MEASURE! ; If you use "Naive", you allow hosts to trick your server to believe they are ; connecting from elsewhere. ; A drastical example is that you set "localhost = AllowStore,AllowRelay" in the ; "Policies\Hosts" table below, thinking that this line only gives RELAY right to ; "127.0.0.1". Then a malicious bot connects your SMTP server which happens to have ; "localhost" as its reverse hostname. If you don't verify the validity of its reverse ; DNS, then MgSMTP will grant it the RELAY right. If you verify its reverse DNS (i.e. ; you have any other setting than "Naive"), you don't let yourself tricked. FCrDNSPolicy = Aware ; The "Policies\Hosts" section defines a list of rights assigned to specific hosts. ; (Actually, it's an ACL.) ; You may use wildcards in the hostnames, and you may also specify IPs. When a ; client connects, MgSMTP will resolve its reverse DNS, and match that hostname and ; the client's IP with the items on the list one by one. If it finds a line that ; matches for either the hostname or the IP, the rights specified in that line will ; be assigned to the connection. ; The assigned rights are specified by lists of the following strings: ; AllowStore - the host will be permitted to send messages destined to this server ; DenyStore - the host will not be allowed to send messages to any local mailboxes ; AllowRelay - the host will be permitted to send messages those need to be relayed ; to another server ; DenyRelay - the host can't send any e-mails destined to foreign servers ; Disconnect - the host won't be allowed to communicate this server at all, any ; connection from such host will be closed with a 554 response code ; Note, in some cases it may be better to block unwanted systems by firewall settings ; instead of assigning the "Disconnect" option to them. ; Here's an example list: ;[Policies\Hosts] ;localhost = AllowStore,AllowRelay ;192.168.1.* = AllowStore,AllowRelay ;evil.com = Disconnect ;*.dontlike.net = DenyStore,DenyRelay ;* = AllowStore,DenyRelay ; So "localhost" will have all permissions, such as all computers on the LAN ; (assuming they are in the subnet 192.168.1.*). The host, evil.com, on the other ; hand will be disconnected, so it won't be allowed to even greet the server. The ; subdomains of dontlike.net will be allowed to communicate to the server, though ; all messages will be rejected from them politely. Any other hosts will be permitted ; to deliver messages destined to this server, but they won't be allowed to relay ; e-mails through it. ; Note, relaying towards hosts those are listed on the "RelayTo" list (see below, at ; section "Relay") doesn't require the "RELAY" right; however it still requires the ; "STORE" right. Don't worry if you don't get it here, just read on - it's explained ; thoroughly somewhere below. ; Here is your default "Policies\Hosts" list, you may change it if you want: [Policies\Hosts] localhost = AllowStore,AllowRelay * = AllowStore,DenyRelay ; The "Policies\Users" section is similar to the above-described "Policies\Hosts" ; section in many ways. The difference, that it assigns rights for specific users, ; who may authenticate themselves with the "AUTH LOGIN" command. Note, rights ; assigned to users will completely override the rights assigned for hosts. What ; does it mean? If a user connects from a host, such as foobar.dontlike.net from the ; above example, she won't have any rights initially. But if she identifies herself ; as user "LBurke", she will have all rights. ; However, a user may even have more restrictive privileges that the connection will ; permit them by default. For example, "Eli" connects from 192.168.1.32 (a host that ; has full rights according to the above example), and authenticates herself. She'll ; lose the "RELAY" right. ; All user accounts must have a password set, see below. ; A user account doesn't need to have a corresponding local mailbox, and generally, ; user accounts have nothing to do with mailboxes. ; Note, it is pointless to supply "Disconnect" in this ACL, because it won't be checked ; and enforced after the user has been greeted. And obviously, if the host the user is ; connecting from has "Disconnect" set in the "Policies\Hosts" ACL, the user won't be ; able to authenticate because they'll get disconnected before they could attempt to. ; Here's our example as an illustration: ;[Policies\Users] ;LBurke = AllowStore,AllowRelay ;Eli = AllowStore,DenyRelay ;SomeGroup = AllowStore,AllowRelay ; And here you may add your own users: [Policies\Users] ; If you add users, you must set their passwords which they can authenticate with, in ; "Policies\Users\" sections. Passwords can be specified by plaintext or by ; their MD5 checksums (the latter is more secure). Also, you can add alias usernames ; for a user. (Though I must admit it's pretty useless since you can't supply distinct ; passwords for them.) ; You can even modify the databytes limit valid for a user - if a user authenticates, ; their databytes limit completely overrides the default databytes limit given in the ; "Spool" section. That means, the user's databytes limit can be either smaller or ; larger than the default. Databytes limit is always specified in bytes. The detailed ; description of "databytes limit" can be found somewhere below, under the "Spool" ; section. ; See the example settings for our example users: ;[Policies\Users\LBurke] ;Auth = On ;Databytes = 134217728 ;PassType = md5 ;Password = 7947ba4e6c4bede8896b1c0e28d5f258 ; ;[Policies\Users\Eli] ;Auth = On ;PassType = plain ;Password = alwaysthirsty ; ;[Policies\Users\SomeGroup] ;Auth = On ;Databytes = 8388608 ;Alias = Monkey,Donkey,Hippo ;PassType = plain ;Password = LuckyAmI ; The "Spool" section defines the behaviour of the message queue. All e-mails are ; queued in the spool after they are received, even local messages. The reason why ; local messages get queued instead of being delivered to the appropriate mailbox ; immediately, is that mailboxes have to be locked when an e-mail is being delivered ; to them. Thus, the mail server couldn't receive more than one e-mails for the same ; mailbox at the same moment. Queueing even local messages allows the server to accept ; multiple e-mails for the same mailbox at once. ; The queue function can't be disabled. [Spool] ; The "Databytes" entry specifies the so-called databytes limit for incoming e-mails. ; (I don't really know why is it actually called "databytes limit", but other mail ; servers name it like that.) ; Unlike mailbox quota, databytes limit sets the maximum size of a single e-mail that ; the mail server is willing to process. The databytes limit set here may get ; overridden for specific users who must authenticate themselves with "AUTH LOGIN". ; (See "Policies\Users\" sections above.) ; The databytes limit is specified in bytes. Databytes = 16777216 ; The "AllowExceedQuota" switch defines the policies of delivery to local mailboxes. ; Assume that a particular mailbox's quota is almost exceeded. Then the mail server ; receives an e-mail with a size that would surely take the mailbox over quota. ; When "AllowExceedQuota" is enabled, the spool will deliver this e-mail to the ; mailbox, so it allows it to exceed its quota. The next e-mail however will be ; refused by the server with an error message (so that won't get into the spool). ; If "AllowExceedQuota" is disabled, the spool won't let the mailbox to get over ; quota, so it guarantees the mailbox will never be bigger than its quota. In that ; case, the spool will generate a Delivery Status Notification to inform the sender ; of the failure. E-mails may still be accepted by the server for such mailboxes, ; they get the error message later. It is not a common technique. ; If the sender is so kind that it supplies a SIZE declaration in its the MAIL command, ; then the server will check the mailbox's quota and refuse the e-mail if it wouldn't ; fit in, when "AllowExceedQuota" is disabled. ; Note, as I see most mail servers allow their users to exceed their quotas with ; one last e-mail. AllowExceedQuota = On ; "MaxReceivedHeaders" is invented to detect possible mail relay loops. In some cases, ; if a mail server is configured incorrectly, it may relay some e-mails to itself, or ; to another mail server that will relay the e-mail back, thus it will be stuck in an ; infinite mail relay loop. To prevent mail relay loops to go far, MgSMTP counts the ; "Received" headers of e-mails, and rejects messages those have "MaxReceivedHeaders" ; or more number of "Received" headers. MaxReceivedHeaders = 16 ; The "DeliveryThreads" key tells the spool how many delivery threads to start. ; These threads constantly watch the spool for e-mails need to be delivered. If your ; server has many messages in the spool, then all your threads get busy, and each ; thread will try to deliver an e-mail. If you have 8 threads for example, then a ; maximum of 8 e-mails will be delivered in paralell. ; NOTE: To avoid collisions of delivery threads, possible first characters of spool ; object names are assigned to specific threads. (Numbers 0-9 and letters A-Z.) ; Thus, one thread will never try to open a spool object that another thread is ; working on. The drawback of this feature is that it maximizes the number of delivery ; threads to 36. If the maximum value is set, each threads will bother only with ; spool objects those names start with one specific number or letter. DeliveryThreads = 8 ; The "ThreadWait" key defines the "heartbeat" of your delivery threads. More ; precisely, the threads will wait a "ThreadWait" number of milliseconds after it ; glanced through the spool for deliverable e-mails, before it checks the spool again. ; The more busy is your server, the smaller "ThreadWait" value you should have. ; If your mail server is really busy, I suggest you to set a value less than 1000. ; NOTE: If you find that your server has a pretty large CPU utilization even when it's ; idle (no messages in spool), you should set a higher "ThreadWait" value. ThreadWait = 1000 ; The "TryCount" value tells the spool how many times should it try to deliver a queued ; message that has temporary failures. The server should keep trying for several days. ; Use the "TryDelay" value to calculate the actual length of trying in time. TryCount = 4320 ; The "TryDelay" value tells the spool the number of MINUTES it has to wait before ; retrying to deliver an e-mail to recipients those failed with temporary errors at ; previous attempts. TryDelay = 2 ; The "TempFailNotifyFirst" switch tells MgSMTP whether to send a temporary failure ; notice after the very first attempt of delivery (if that fails with a temporary ; failure). It's not a common setting by the way. ; According to my own experiences, this option comes really handy for testing relay ; configuration, and it is useful when you get noticed that your e-mail delays, ; even if it's because of greylisting on the target server. ; But in some cases it can be very annoying when random folks out there receive ; temporary failure notifications from your mail system at the first place, and in ; the case if they don't know anything about how do SMTP networks work, they can ; easily interpret your temporary failure notification as permanent... TempFailNotifyFirst = On ; MgSMTP sends temporary failure notices of undelivered messages after "TempFailNotify" ; tries. If the setting is 1440 for example, a failure notice will be sent after ; the 1440th try, then the 2880th try, then the 4320th try, and so on. If a number of ; "TryCount" tries has been reached, a permanent failure notice will be sent in any ; way, and the queued message will be administered and deleted as failed. TempFailNotify = 1440 ; If "KeepProcessedEnvelopes" is enabled, MgSMTP will move the .DAT files of processed ; e-mails to the "processed" directory, instead of removing them. There you can see ; the final state of the "spool object"/".DAT file"/"envelope", or whatever you would ; like to call it. The .DAT file is actually in INI format, it's quite easy to read and ; understand. KeepProcessedEnvelopes = Off ; If "KeepProcessedEMails" is enabled, MgSMTP will move processed e-mails (stored in ; .EML files) to the "processed" directory, instead of deleting them. Note, this ; option actually allows you to see/archive all e-mails passed through your SMTP ; server. If there are more people using your system, it may involve moral questions. ; Moreover, if there are many large e-mails passing through your server, it may fill ; up a lot of space in a short time. KeepProcessedEMails = Off ; The "Mailbox" section contains settings regarding local mailboxes. [Mailbox] ; This is the global quota setting - it will apply to any mailboxes those don't have ; a specific quota set. If you set it to "0", the quotas will be unlimited. Quota = 67108864 ; Enable plus aliases: allow an alias to be expanded to the mailbox name with a "+" sign. ; E.g.: and will automatically ; address the same mailbox without having to list them on an "Alias" list or anything. ; You can safely make up as many +alias addresses as you want without having to change ; the mail server config. ; FYI: GMail also supports this, e.g. if you send e-mail to , ; you will receive it into your mailbox at . ; If "PlusAliases" is turned off, "+" characters in mailbox addresses will not be treated ; specially in any way. PlusAliases = On ; You have the opportunity to disable some plus aliases - e-mails destinated to such ; aliases will be rejected. ; In this example, e-mails to and ; will be rejected, while other plus aliases like will continue ; to work. This is useful when you start to get unsolicited e-mails to one of your ; plus-aliased e-mail addresses, and you want to put an end on it: the best part is that ; it won't affect other aliases for your mailbox. ; "PlusAliasExcept" is the global, mail-server-wide setting, which will be default for ; all mailboxes those don't have this directive, but will be completely overridden if ; set for an individual mailbox. ; "GlobalPlusAliasExcept" will be added to the "PlusAliasExcept" list of all individual ; mailboxes. ;PlusAliasExcept = spam,viagranews ;GlobalPlusAliasExcept = ; Below you can enable "domain-specific mailboxes", which allows you to set up a limited ; form of virtual hosting. Assume your mail server is receiving e-mails for ; yourdomain.com and otherdomain.com. Both of these domains are supplied at ; "Server\Name" or "Server\Alias". Then you'd like to run 2 separate mailboxes for ; info@yourdomain.com and info@otherdomain.com. If you simply create a file named ; "info" in the "mail" directory, then both of the mentioned e-mail addresses will ; address that single mailbox, while you want separate mailboxes. ; The "DomainSpecific" option enables a feature that allows you to create mailboxes ; those are only valid for a specific alias domain. To use it, create mailbox files in ; the "mail" directory by supplying their domains as well: create files named ; "info@yourdomain.com" and "info@otherdomain.com". ; Note that this is not standard - it is not ensured that your e-mail client will be ; able to read your mailbox files, or your POP3/IMAP server (if you have such - really, ; if you have a suitable open-source POP3 or IMAP server for Windows, please tell me!) ; will handle such mailboxes. The POP3 protocol, in fact, doesn't support virtual ; hosting at all. DomainSpecific = Off ; Enable or disable the rewriting feature globally. If disabled, none of the ; "RewriteTo" lines will be in effect. (See below.) Rewrite = Off ; Global "RewritePassThru" setting. It will be applied to all mailboxes on which you ; don't set a "ForwardHeaders" value explicitly. (See individual mailboxes for ; explanation.) RewritePassThru = On ; Default "RewriteTo" setting. Please only fill it if you really find it necessary. ; In most cases, you'd better provide RewriteTo lists for individual mailboxes only. ;RewriteTo = ; Enable or disable the forwarding feature globally. If disabled, none of the ; "ForwardTo" lines will be in effect. (See below.) Forward = Off ; Global "ForwardHeaders" setting. It will be applied to all mailboxes on which you ; don't set a "ForwardHeaders" value explicitly. (See individual mailboxes for ; explanation.) ForwardHeaders = On ; Default "Remail" setting for mailboxes. (See below.) Remail = On ; Default "StoreLocalCopy" setting for mailboxes. (See below.) StoreLocalCopy = On ; Default "ForwardTo" setting. Please only fill it if you really find it necessary. ; In most cases, you'd better provide ForwardTo lists for individual mailboxes only. ;ForwardTo = ; "Mailbox\" sections define settings for specific mailboxes. Note, it is not ; mandatory to have such sections for all existing mailboxes. If there is nothing ; specific to set for a mailbox, then it's useless to have a section for it here. ; If you have sections for non-existent mailboxes, those will be ignored. ; Here's an example section for a hypothethical mailbox named "foobar": ;[Mailbox\foobar] ;Quota = 8388608 ;Alias = moo,cow ; Obviously, the "Quota" setting sets the quota for the specific mailbox. The "Alias" ; list adds aliases to the mailbox, so it will be accessed by multiple names. ; Rewriting and forwarding: ;[Mailbox\info] ;RewriteTo = you@gmail.com ;RewritePassThru = On ; The "info" mailbox above utilizes rewriting. Whenever the mail server receives an ; e-mail for this mailbox, MgSMTP will also add "you@gmail.com" to the envelope as ; recipient, as if the client would have sent the e-mail to that address too. (The ; client doesn't need to have relay rights, rights are not checked upon rewriting.) ; "RewritePassThru" controls whether the original recipient should be kept: if it's ; "Off", the e-mail won't be delivered to the "info" mailbox, it will only be sent to ; "you@gmail.com". ; Be aware that rewriting is not recursive! ; Also, since rewriting takes effect when an e-mail is received from a client, ; rewriting won't be applied to internally generated e-mails (such as DSNs, forwarded ; messages). ;[Mailbox\monkey] ;ForwardTo = you@gmail.com ;ForwardHeaders = On ;StoreLocalCopy = On ; The "monkey" mailbox utilizes forwarding. When MgSMTP is about to deliver a message ; to this mailbox, the message will be copied, and the copy will be sent to ; "you@gmail.com". If "ForwardHeaders" is enabled, MgSMTP will add an "X-Forwarded-For" ; and an "X-Forwarded-To" header to make this event traceable. ; If "StoreLocalCopy" is disabled, the message won't be delivered to the originally ; addressed "monkey" mailbox, it will be just forwarded on-the-fly. ; In the case of forwarding, the original Return-Path will be used for the copied ; message. ;[Mailbox\donkey] ;ForwardTo = you@gmail.com ;ForwardHeaders = On ;StoreLocalCopy = On ;Remail = On ; The "donkey" mailbox utilizes remailing. Remailing is pretty much like forwarding, ; except that the Return-Path of the copied message will be replaced by the address ; of the actual mailbox ("donkey@yourdomain.com", in this case). This has several ; advantages: ; - incidental failure notices will arrive to "donkey", instead of the unsuspecting ; sender of the original message who should not be aware of the remailing (assume ; "donkey" still visits his mailbox here as well for time to time, so he'll see his ; failure notices); ; - if the target domain uses the SPF SPAM filtering technique (GMail does, for ; example), the result will depend on your domain's SPF record (which is controlled ; by you, hopefully), and not on the original sender's one, which supposedly won't ; designate your host as a permitted sender for their domain. ; Remailing won't be applied to DSNs (or any e-mails with empty Return-Path), because ; supplying a Return-Path for such a message could easily cause a remailing loop. Such ; messages will be simply forwarded instead. ; Note: Both "RewriteTo" and "ForwardTo" keys are lists, so you can supply multiple ; addresses separated by commas. E.g.: ; ForwardTo = jane@nowhere.com,jack@somewhereelse.com ; ESSENTIAL DIFFERENCES BETWEEN REWRITING AND FORWARDING/REMAILING: ; In the case of rewriting, the original message's envelope will get modified before the ; server receives the e-mail. This means, rewriting happens before the message gets to ; the spool. No headers can be added to track what was rewritten to what. The message ; will seem like it was just relayed through your SMTP server, as if it was addressed to ; the rewritten address originally. ; On the other hand, forwarding happens after the message has been stored in the spool. ; It happens when the spool delivers the message to the local recipient. Then the ; message gets copied, and the copy will be sent to the forward addresses. The copy will ; contain "X-Forwarded-*" headers (if "ForwardHeaders" is on), and an additional ; "Received" header. If the original message has been actually stored to the originally ; addressed mailbox as well (depends on "StoreLocalCopy"), a "Delivered-To" header will ; be also present. ; Rewriting is not recursive, while forwarding/remailing is. Rewriting won't apply to ; internally generated e-mails (such as DSNs and forwarded messages), while forwarding ; will. ; Since forwarding/remailing is more traceable, and remailing also protects you from ; negative SPF results, forwarding or remailing is usually more preferable over ; rewriting. However, rewriting is a much simpler and resource cheaper operation than ; forwarding. I suggest to use rewriting for addresses within your network, or to add ; aliases for domain-specific mailboxes those belong to other alias domains. To forward ; mail to other domains, use forwarding or remailing! ; USING BOTH REWRITING AND FORWARDING ON A SINGLE MAILBOX: ; It's possible, but "RewritePassThru" must be enabled to allow forwarding to apply! ; (You can still have "StoreLocalCopy" off, if you don't want your message to be ; actually delivered to the mailbox.) ; Reply addresses and simple distribution lists: ; As the following example shows, with the combination of "ForwardTo" and "ReplyTo", ; it is possible to create simple, static distribution lists, where replies are ; addressed back to the distribution list by default. ; The value of "ReplyTo" will be inserted as a "Reply-To" header to the e-mails being ; forwarded. Note, it will only affect forwarded e-mails: the local copy won't have ; the "Reply-To" header. ; There is a special value for "ReplyTo": "!". When used, it will be substituted with ; the appropriate mailbox address (in this example, it is "party@example.com"). ;[Mailbox\party] ;ForwardTo = benga@example.com,hugo@example.com,kitty@example.com ;ReplyTo = Party Unit ; Or: ;ReplyTo = ! ; Domain-specific mailboxes: ;[Mailbox\@mydomain.tld] ;Quota = 0 ;ForwardTo = littlekittens@yourdomain.tld ;GlobalPlusAliasExcept = dogs ;[Mailbox\info@otherdomain.com] ;Alias = contact,information ; Here are a some rules applying to domain-specific mailboxes: ; - If you have an "info@otherdomain.com" file in your "mail" folder, then it will only ; override the "info" mailbox, unless "info@otherdomain.com" has aliases. So the ; mailbox "sam" will still receive e-mails for all alias domains (assuming there are ; no domain-specific mailboxes with username "sam"). ; - If you have both "info" and "info@otherdomain.com" files in your "mail" folder, then ; the former mailbox will still receive e-mails for all alias domains, except ; otherdomain.com. ; - If you have aliases for "info@otherdomain.com", those will be only valid for ; otherdomain.com. The aliases for a domain-specific mailbox will override the normal ; mailboxes with the corresponding names, see the 2nd point above. ; - If you want to add aliases for domain-specific mailboxes those belong to other ; domains (i.e. you want to add "monkey@xxdomain.com" as an alias for ; "donkey@yydomain.com"), the normal "Alias" key won't work! In this case, you need to ; use "RewriteTo" or "ForwardTo". ; - Most mailbox-specific settings can be set under [Mailbox\@mydomain.tld] sections, ; which makes them the default for the domain-specific mailboxes belong to the given ; domain. This won't have an effect on mailboxes those are not domain-specific (i.e. ; their mailbox file name doesn't have a "@" sign), even if they are addressed by ; an alias domain. ; The "Relay" section defines the server's relay rules. [Relay] ; The "RelayTo" list gives hostnames which the server is designated to relay towards. ; Even hosts those don't have the RELAY right will be allowed to relay towards these ; addresses. (However, those hosts still need to have the STORE right to be eligible ; to relay to "RelayTo" addresses.) In an aspect, MgSMTP considers recipient addresses ; destinating to a host listed on the "RelayTo" list as local. ; You need to use this for setting up backup MX servers. ; It can be also useful if you'd like to receive e-mails for a computer on your LAN. ; RelayTo = abcdef.com,ghijkl.org ; The "NoRelayTo" list is the exact opposite of the "RelayTo" list: it prevents ; relaying to specific domains, even for clients those would be permitted to relay ; otherwise. ; NoRelayTo = forumspammer.net ; The "Relay\Routes" section defines a routing table. You can specify a mask on the ; left sides of each item of the list. On the right side, you can specify a host where ; you would like to relay matching addresses. You can define a host by giving its ; hostname, or by associating a symbolic name you choose. If you use a symbolic name, ; you must expand the settings applying to that host in a distinct section (see below). ; A special character may also be used: "!", it means e-mails for those hosts will be ; relayed to the named host directly. ; See this example: ;[Relay\Routes] ;donkey.net = monkey.org ;*.lucky.com = ! ;foobar.com = foobar.com ;* = MyISP ;[Relay\Routes\foobar.com] ;Port = 600 ;[Relay\Routes\MyISP] ;Host = mail.myisp.net ;Auth = On ;Username = myusername ;Password = mypassword ; According to this example, e-mails addressed to host donkey.net will be relayed ; to monkey.org. (So e-mails addressed to anything@donkey.net will be actually sent to ; the MX-es of monkey.org.) ; E-mails destined to whatever.lucky.com will be passed to the MX-es of ; whatever.lucky.com, as it would be normal. ; E-mails destined to foobar.com will be delivered to the MX-es of foobar.com, but ; they will be connected on an alternate port (600). ; Any other e-mails will be relayed through your ISP's SMTP, defined by the symbolic ; name, "MyISP". Settings for "MyISP" are defined in a distinct section. There, the ; real hostname of the ISP's SMTP server is specified. This SMTP server requires user ; authentication, it is indicated by the "Auth" switch, and of course, the username ; and the password need to be revealed as well. MgSMTP will authenticate itself with ; "AUTH LOGIN" at the ISP's SMTP server when it relays e-mails through it. ; Note, you don't have any option to store this password in an encrypted form. So it is ; crucial to deny all unwanted users to view this file. ; Here is your default routing table: [Relay\Routes] * = ! ; The "Log" section configures MgSMTP's logging behaviour. [Log] ; Maybe you are glad that there aren't a lot of things to be set here. ; MgSMTP writes its log to "smtp.log" in its own directory. You can override this ; default filename if you want. Filename = smtp.log ; That's all, folks. I told you, it's a minimal-featured SMTP server. But anyway, if ; you miss something, tell me your ideas by sending an e-mail to ; .