Tài liệu Chapter-27-Electronic mail -servers pptx

Specifically, they perform three related tasks: • They send outgoing mail, in other words mail that originates from their system.. • They receive incoming mail, possibly for multiple dom

Electronic mail:

ser vers

In this chapter:

delivered

• Installing postfix

boot time

from your ISP

majordomo

In this chapter:

delivered

• Installing postfix

boot time

from your ISP

majordomo

In the previous chapter, we looked at email from a user perspective The other part of a

mail system is the Mail Transfer Agent, or MTA As the name suggests, MTAs perform

the transfer of mail from one system to another Specifically, they perform three related tasks:

• They send outgoing mail, in other words mail that originates from their system If the destination system is not available, they look for an alternative system, and if none is available, they retry delivery at a later date Typically an MTA will retry every 30 minutes for five days before giving up

• They receive incoming mail, possibly for multiple domain names They may be quite picky about how they perform this task: since the advent of spam, a number of

techniques have dev eloped We’ll look at some in the section on postfix

configuration

• They relay mail Consider the case where a sending MTA can’t reach the destination MTA and chooses an alternative The alternative MTA is called a relay, and it must

be prepared to deliver the mail to the final recipient at a later time Until a few years ago, MTAs performed relaying by default, but the advent of spam has changed that radically

Mail has been around for a long time now, well over 25 years In that time, many mail

systems have come and gone One seems to have been around for ever: the sendmail MTA sendmail has an unparalleled reputation On the one hand, it can do just about

anything, but on the other hand, its configuration file is one of the most arcane ever to be

seen Still, it’s holding well against the competition, and it is still actively being developed

The definitive book on sendmail, called the ‘‘bat book’’ after its cover, was written by Bryan Costales and others (O’Reilly)—see Appendix A, Bibliography for more details.

It is over 1000 pages long Obviously this book can’t compete with it

The good news about sendmail is: it works It is possible to install sendmail and run it

with no configuration whatsoever The less good news is that in the past few years it has been constantly changing, and any information I write here is liable to be out of date by the time you read it As a result, I recommend:

If sendmail works for you, use it If you have difficulties, use

postfix instead.

The following sections show how to configure a mail system using postfix In general, sendmail is quite similar You’ll find every detail in the bat book, and the original sendmail distribution, available from http://www.sendmail.org/ , contains instructions for

experts

How mail gets delivered

Ideally, to send mail, the source MTA contact the destination MTA and sends the message In practice, this doesn’t always work Here’s the general method:

• Each time an MTA receives a message not addressed to its system, this MTA collects all MX records for the destination that are not higher than its own MX record

• If the MTA finds any MX records, it attempts to send to one of them, starting at the lowest preference

• If the lowest MX record points to the MTA’ s own machine, then there’s a mail misconfiguration: the MTA doesn’t know what to do with it locally, but the MX is telling it to deliver it locally When this happens, the MTA reject the message (‘‘mail loops back to myself’’)

• If there are no MX records at all (which implies that the MTA doesn’t hav e one either), most, but not all versions of sendmail will look up an A record for the system name If they find one, they will try to deliver there, and only there

• If all else fails, the MTA rejects the message (‘‘can’t find the destination’’)

MTA files

MTAs use three different kinds of files:

• Configuration files tell the MTA what to do Typical configuration issues include what name to present to the outside world, and when to accept mail for delivery and when to reject it The issue of spam (unsolicited commercial email) makes this quite

a complicated issue postfix keeps its configuration files in the directory /usr/lo-cal/etc/postfix, and sendmail keeps them in /etc/mail.

• Outgoing postfix mail is stored in the directory hierarchy /var/spool/postfix, while sendmail currently stores its mail in the hierarchies /var/spool/mqueue and /var/spool/clientmqueue.

• Incoming mail is stored in the directory /var/mail Normally each user gets a file that

corresponds to his user name

Who gets the mail?

According to RFC 2822, a mail ID is something likegrog@example.org This looks very much like a user ID, the@ sign, and the name of a machine This similarity is

intended, but it’s still only a similarity Consider the system manager of example.org At different times he might send mail from freebie.example.org, bumble.example.org, and wait.example.org If the mail ID were associated with the machine, he would have three

different mail IDs: fred@freebie.example.org, fred@bumble.example.org and

fred@wait.example.org It would make things a whole lot simpler (and easier to type) if his mail ID were simply fred@example.org This name change is called

masquerading.

One way to do this would be to associate the nameexample.orgas aCNAMEwith one of

the machines—say wait.example.org This would work, but it would mean that mail would always have to come from and go to wait.example.org If for any reason that

machine were inaccessible, the mail would not get through In practice, it’s possible to run MTAs on more than one machine DNS solves this problem with a special class of record, theMXrecord (mail exchanger) MX records can point to more than one machine,

so if one machine is not accessible, the mail can be sent to another We saw how to add them on page 370 MX records are not directly associated with any particular machine, though they point to the names of machines that run an MTA

Installing postfix

postfix is in the Ports Collection, not the base system, so before you can use it, you must install it It is an interactive port: at various points in the installation process it asks for

input The first is a menu offering optional additional configurations, as shown in Figure 27-1 For the configuration in this book, you don’t need anything in addition to what the menu suggests; just selectOKand continue

Some time later you get the informational messages:

Added group "postfix".

Added group "maildrop".

Added user "postfix".

You need user "postfix" added to group "mail".

Would you like me to add it [y]? Enterpressed

Done.

mta.mm,v v4.15 (2003/04/02 05:01:57)

Figure 27-1: Postfix configuration menu

The build continues for a while, and finally you get the information:

Installed HTML documentation in /usr/local/share/doc/postfix

===> Generating temporary packing list

Would you like to activate Postfix in /etc/mail/mailer.conf [n]? y

The output goes on to explain which flags to set in your system configuration file

/etc/rc.conf In particular, it tells you to setsendmail_enableand finishes by saying

‘‘This will disable Sendmail completely.’’ This may look strange, especially if you don’t

have any sendmail-related entries in /etc/rc.conf Why should settingsendmail_enable

toYESdisable sendmail? Well, it’s a somewhat unfortunate choice of naming, and it’s

possible it will change, but the answer is in the details:sendmail_enableshould really

be called something like mail_enable The other sendmail parameters turn off all sendmail-related components.

Configuring postfix

postfix requires only one configuration file, /usr/local/etc/postfix/main.cf This file

contains a large number of comments: with a little experience you can configure it without any outside help In this section, we’ll look at some of the entries of interest

# The mail_owner parameter specifies the owner of the Postfix queue

# and of most Postfix daemon processes Specify the name of a user

# account THAT DOES NOT SHARE ITS USER OR GROUP ID WITH OTHER ACCOUNTS

# AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM In

# particular, don’t specify nobody or daemon PLEASE USE A DEDICATED

# USER.

#

mail_owner = postfix

Older MTAs used to run asroot, which made it easier to write exploits transmitted by mail Modern MTAs use a dedicated user ID As we saw above, thepostfixuser gets

added to your password files when you install it sendmail uses another user ID,smmsp Don’t change this entry

Host and domain names

A significant portion of the configuration file defines host names By default, the variable

myhostnameis the fully qualified host name of the system, for example freebie.exam-ple.org You should normally leave it like that; it’s not identical to the name that will appear on outgoing mail

The next variable ismydomain, which defaults to the domain name of the system Again, you won’t normally want to change it

Then comes the variablemyorigin, which is the name that appears on outgoing mail It defaults tomyhostname, which is probably not a good choice As suggested above, a better name would be the domain name, mydomain Make the following changes to

main.cf :

# The myorigin parameter specifies the domain that locally-posted

# mail appears to come from The default is to append $myhostname,

# which is fine for small sites If you run a domain with multiple

# machines, you should (1) change this to $mydomain and (2) set up

# a domain-wide alias database that aliases each user to

# user@that.users.mailhost.

#

#myorigin = $myhostname

myorigin = $mydomain

In the original configuration file, the last line is present, but it is ‘‘commented out’’: it starts with the#character Just remove this character

The next variable of interest ismydestination This is a list of host and domain names for which the MTA considers itself the final destination (in other words, it accepts mail for final delivery) By default, it accepts mail addressed to the name of the machine ($myhostname in postfix parlance) and also localhost.$mydomain, the local host

name for this domain In particular, it does not accept mail addressed to the domain, so if

you send mail as fred@example.org, any reply will bounce To fix this, add

$mydomainto the list

You might also want to accept mail for other domains For example, if you also wanted

to accept mail for beispiel.org, you would add that name here as well The result might

look like this:

#mydestination = $myhostname, localhost.$mydomain

#mydestination = $myhostname, localhost.$mydomain $mydomain

mydestination = $myhostname, localhost.$mydomain, $mydomain,

beispiel.org

For the mail for beispiel.org to actually be delivered to this machine, the lowest priority

mta.mm,v v4.15 (2003/04/02 05:01:57)

MX record for beispiel.org must point to this host.

Further down, we’ll see a feature called virtual hosting This is a way to allocate email

addresses to people without a UNIX account on this machine It works at the user level, not the domain name level

Relaying mail

One of the favourite tricks of spammers is to send their mail via another system to give it the aura of respectability This is doubly annoying for the ‘‘other’’ system: first, it gives it the reputation of being a spammer, and secondly it often incurs expense, either for data

charges or simply from congestion postfix has a number of tricks to help The first specifies which networks to trust: postfix will relay mail coming from these networks You could consider this to be ‘‘outgoing’’ mail, though the methods postfix uses don’t make this assumption By default, postfix trusts your network and the localhost network

127.0.0.0/8, in other words with a net mask 255.0.0.0 But how does it know the net mask for your network? There are two possibilities: you tell it, or it guesses

postfix is pretty simplistic when it comes to guessing It takes the default net mask for

the address class, so if your IP address is, say, 61.109.235.17 (a ‘‘class A’’ network), it will accept mail from any network whose first octet is 61 I know of at least 20 sources of spam in that range In almost every case, you should specify the network and mask explicitly:

mynetworks = 223.147.37.0/24, 127.0.0.0/8

This is a good choice where you know the name of the originating networks, for example systems that expect you to handle the mail connection to the outside world But what if you want to accept mail from anywhere addressed to specific domains? Consider this

‘‘incoming’’ mail, though again that’s not the way postfix looks at it For example, maybe you’re a backup MX for beispiel.de, so you want to accept any mail sent to that

domain In that case, you want to relay mail to this domain no matter where it comes from For this case, use therelay_domainsvariable, a list of domain names for which

postfix will always relay You might put this in your main.cf :

relay_domains = $mydestination, $mydomain, beispiel.de

You can also use thepermit_mx_backupvariable to accept mail for any domain that lists you as a secondary MX This is very dangerous: you don’t hav e any control over who lists you as a secondary MX, so any spammer could take advantage of this setting and use you for a relay

Aliases revisited

On page 481 we looked at how to set up individual aliases for use with mutt postfix and sendmail also have an alias facility, this time at the system level The system installs a file called /etc/mail/aliases It’s there by default, so there’s no particular reason to move

it The default /etc/mail/aliases looks like:

# Basic system aliases these MUST be present

MAILER-DAEMON: postmaster

postmaster: root

# General redirections for pseudo accounts

bin: root

daemon: root

games: root

ingres: root

nobody: root

system: root

toor: root

uucp: root

# Well-known aliases these should be filled in!

# root:

# manager:

# dumper:

# operator:

root: grog

Each line contains the name of an alias, followed by the name of the user who should receive it In this case, mail addressed to the users bin, daemon, games, ingres,

nobody,system,tooranduucpwill be sent torootinstead Note that the last line redefinesrootto send all mail to a specific user

You must run the newaliases program after changing /etc/aliases to rebuild the aliases database Don’t confuse this with the newalias program, which is part of the elm MUA.

A couple of other uses of aliases are:

• You can also use an alias file for spam protection If you want to subscribe to a mailing list, but you are concerned that spammers might get hold of the contents of the mailing list, you could subscribe as an alias and add something like:

frednospamplease: fred

If you do get spam to that name, you just remove the alias (and remember never to have any dealings with the operator of the mailing list again)

• Another use of aliases is for majordomo, the mailing list manager we’ll look at on

page 503

By default, postfix doesn’t hav e a specific alias file main.cf contains:

#alias_maps = dbm:/etc/aliases

#alias_maps = hash:/etc/aliases

#alias_maps = hash:/etc/aliases, nis:mail.aliases

#alias_maps = netinfo:/aliases

The textsdbm,hashandnetinfodescribe the kind of lookup to perform For sendmail

compatibility, we wanthash Assuming you also want to run majordomo, add the line:

mta.mm,v v4.15 (2003/04/02 05:01:57)

alias_maps = hash:/etc/mail/aliases,hash:/usr/local/majordomo/aliases.majordomo

Rejecting spam

One of the biggest problems with email today is the phenomenon of spam, unsolicited

email Currently the law and ISPs are powerless against it Hopefully the community will find solutions to the problem in the future, but at the moment keeping spam to manageable proportions is a battle of wits There are a number of ways to combat it, of course:

• Reject mail from domains known to be spammers postfix helps here with a file called /usr/local/etc/postfix/access, which contains names of domains to reject.

There are a couple of problems with this approach:

• It’s relatively easy to register a domain, so you may find the same spam coming from a different location

• It’s relatively easy to spoof a domain name Mail is regularly relayed, so you

have to go by the name on theFromline But you can forge that, so you often see mail from yahoo.com or hotmail.com that has never been near those ISPs Obviously it doesn’t help to complain to the ISP

• Of course, if the names are spoofed, you can still find out where the message really came from from the headers, as we saw on page 482 Or can we? There are two

issues there: firstly, if the message has gone by another system, a relay, you can’t rely

on the headers further back than one hop Anything beyond that can be forged

In the olden days, MTAs would accept mail for relaying from any system: they were

so-called open relays Spammers have found this very useful, and now most systems

have restricted relaying to specific trusted systems There are still a large number of open relays on the net, though

This is a problem that could theoretically happen to you: if your system is an open relay, you could end up delivering spam without even knowing it By default, all current MTAs supplied with FreeBSD refuse to relay, but it’s possible to (mis)configure them to be open relays Be aware of the problems

But what if you get a message like this?

Received: from femail.sdc.sfba.home.com (femail.sdc.sfba.home.com [24.0.95.82])

by wantadilla.lemis.com (Postfix) with ESMTP id BCBFF6ACC0

for <webmaster@lemis.com>; Tue, 19 Jun 2001 13:50:57 +0930 (CST)

Received: from u319 ([24.21.217.142]) by femail2.sdc1.sfba.home.com

(InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP

id <20010619042005.FBWM26828.femail2.sdc1.sfba.home.com@u319>;

Mon, 18 Jun 2001 21:20:05 -0700

From: britneyvideo1234@yahoo.com

To:

Subject: stolen britney spears home video!!!

Date: Thu, 19 Jun 2025 13:52:44 -0200

This message has come from the domain home.com, though it’s claiming to come from yahoo.com, but the IP address of the originating MTA does not resolve to a

name The format of theReceived:headers is:

announced-name (real-name [real-IP])

The first header is correct: the name it claims to be (femail.sdc.sfba.home.com) matches the reverse lookup In the second case though, u319 is not a valid

fully-qualified domain name, and there is no second name: the reverse lookup failed Some

MTAs use the word unknown in this case, and some even add a warning.

Why should the IP of an MTA not resolve? It’s ideal for spammers, of course: it makes them almost impossible to trace In this case, it’s probable that the IP range

belongs to home.com, because they accepted the message for relaying, but the lack of

a valid reverse lookup says nothing for their professionalism

• A number of commercial and public service sites maintain a list of known spam sites You can use them to decide whether to accept a mail message

• The previous example shows another obvious point: this message has been forged to appear to come fromyahoo.com All messages that really come from Yahoo! have a header of this nature:

Received: from web11207.mail.yahoo.com (web11207.mail.yahoo.com [216.136.131.189])

by mx1.FreeBSD.org (Postfix) with SMTP id 4079E43E65

for <freebsd-arch@freebsd.org>; Mon, 7 Oct 2002 10:39:14 -0700 (PDT) (envelope-from gathorpe79@yahoo.com)

So if you can recognize messages claiming to come fromyahoo.com, but without this kind of header, there’s a good chance that they’re spam

So how do we use this information to combat spam? postfix helps for the first three, but

we need other tools for the last

The rules for blocking unwanted messages are not included in /usr/local/etc/post-fix/main.cf Instead, they’re in /usr/local/etc/postfix/sample-smtpd.cf Copy those you want to the bottom of your /usr/local/etc/postfix/main.cf Specifically, the variables of

interest are smtpd_helo_restrictions (which relates to the sending MTA, which could be a relay), andsmtpd_sender_restrictions, which relates to the (claimed)

original sender See sample-xmtpd.cf for details of all possible restrictions The more

interesting ones are:

• reject_unknown_client: reject the request if the client hostname is unknown, i.e

if the DNS reverse lookup fails

• reject_maps_rbl: reject if the client is listed under$maps_rbl_domains We’ll discuss this below

• reject_invalid_hostname: reject hostname with bad syntax

mta.mm,v v4.15 (2003/04/02 05:01:57)

• reject_unknown_hostname: reject hostname without DNS A or MX record.

• reject_unknown_sender_domain: reject sender domain without A or MX record This is probably a forged domain name

• check_sender_access maptype:mapname Look the sender address up in the specified map and decide whether to reject it We’ll look at this in more detail below

• reject_non_fqdn_hostname: reject HELO hostname that is not in FQDN form

• reject_non_fqdn_sender: reject sender address that is not in FQDN form

Rejecting known spam domains

If you have identified domains that you would rather not hear from again, use the form

check_sender_access maptype:mapname By default, the map is stored in /usr/lo-cal/etc/postfix/access.db Add the following text to main.cf :

smtpd_sender_restrictions = hash:/usr/local/etc/postfix/access

Note that the db is missing from the name Now add this line to the file

/usr/local/etc/postfix/access, creating it if necessary:

spamdomain.com 550 Mail rejected Known spam site.

This form rejects messages from this domain with SMTP error code 550 and the message that follows

As we have seen, postfix reads the file /usr/local/etc/postfix/access.db, not /usr/lo-cal/etc/postfix/access Use the postmap program to create or update /usr/local/etc/post-fix/access.db:

# postmap /usr/local/etc/postfix/access

The changes to /usr/local/etc/postfix/main.cf depend on other items as well, so we’ll look

at them at the end of this discussion

To judge by the name, spamdomain.com is probably a hard-core spam producer But

there are others, notably large ISPs with little or no interest in limiting spam, and they also have innocent users who will also be blocked If you find out about it, you can make exceptions:

spamdomain.com 550 Mail rejected Known spam site.

innocent@spamdomain.com OK

Don’t forget to re-run postmap after updating alias One way is to create a Makefile in /usr/local/etc/postfix with the following contents: