[mgsmtp.git] / mgsmtp_server_example.ini

; MegaBrutal's SMTP Server (MgSMTP)
; Copyright (C) 2010-2011 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\<username>" 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\<username>" 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


; 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\<name>" 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.)

; Domain-specific mailboxes:

;[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".


; 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
; <megabrutal@mgsmtp.eu>.