Linux Web Hosting

OK Accept the mail message. RELAY Accept messages

webmaster — Tue, 02 Oct 2007 15:27:51 +0000

OK Accept the mail message. RELAY Accept messages from this host or user even if they are not destined for our host; that is, accept messages for relaying to other hosts from this host. REJECT Reject the mail with a generic message. DISCARD Discard the message using the $#discard mailer. ### any text Return an error message using ### as the error code (which should be RFC-821 compliant) and any text as the message. An example /etc/mail/access might look like: friends@cybermail.com REJECT aol.com REJECT 207.46.131.30 REJECT postmaster@aol.com OK linux.org.au RELAY This example would reject any email received from friends@cybermail.com, any host in the domain aol.com and the host 207.46.131.30. The next rule would accept email from postmaster@aol.com despite the fact that the domain itself has a reject rule. The last rule allows relaying of mail from any host in the linux.org.au domain. To enable the access database feature, use the following declaration in your sendmail.mc file: FEATURE(access_db) The default definition builds the database using hash -o /etc/mail/access, which generates a simple hashed database from the plain text file. This is perfectly adequate in most installations. There are other options that you should consider if you intend to have a large access database. Consult the sendmail book or other sendmail documentation for details. Barring users from receiving mail If you have users or automated processes that send mail but will never need to receive it, it is sometimes useful to refuse to accept mail destined for them. This saves wasted disk-space storing mail that will never be read. The blacklist_recipients feature, when used in combination with the access_db feature, allows you to disable the receipt of mail for local users. To enable the feature, you add the following lines to your sendmail.mc file, if they’re not already there: FEATURE(access_db) FEATURE(blacklist_recipients) To disable receipt of mail for a local user, simply add his details into the access database. Usually you would use the ### entry style that would return a meaningful error message to the sender so they know why the mail is not

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

mailing to collections of e-mail addresses, Usenet news,

webmaster — Tue, 02 Oct 2007 04:15:52 +0000

mailing to collections of e-mail addresses, Usenet news, or mailing lists. Such practises have caused outrage and aggressive reaction by many net users against the individuals concerned. Fortunately, sendmail includes some support for mechanisms that can help you deal with unsolicited mail. The Real-time Blackhole List The Real-time Blackhole List is a public facility provided to help reduce the volume of unsolicited advertising you have to contend with. Known email sources and hosts are listed in a queryable database on the Internet. They’re entered there by people who have received unsolicited advertising from some email address. Major domains sometimes find themselves on the list because of slip-ups in shutting down spam. While some people complain about particular choices made by the maintainers of the list, it remains very popular and disagreements are usually worked out quickly. Full details on how the service is operated may be found from the home site of the Mail Abuse Protection System at http://maps.vix.com/rbl/. If you enable this sendmail feature, it will test the source address of each incoming mail message against the Real-time Blackhole List to determine whether to accept the message. If you run a large site with many users, this feature could save a considerable volume of disk space. This feature accepts a parameter to specify the name of the server to use. The default is the main server at rbl.maps.vix.com. To configure the Real-time Blackhole List feature, add the following macro declaration to your sendmail.mc file: FEATURE(rbl) Should you wish to specify some other RBL server, you would use a declaration that looks like: FEATURE(rbl,`rbl.host.net’) The access database An alternative system that offers greater flexibility and control at the cost of manual configuration is the sendmail access_db feature. The access database allows you to configure which hosts or users you will accept mail from and which you will relay mail for. Managing who you will relay mail for is important, as it is another technique commonly employed by spamming hosts to circumvent systems such as the Real-time Blackhole List just described. Instead of sending the mail to you directly, spammers will relay the mail via some other unsuspecting host who allows it. The incoming SMTP connection then doesn’t come from the known spamming host, it instead comes from the relay host. To ensure that your own mail hosts aren’t used in this way, you should relay mail only for known hosts. Versions of sendmail that are 8.9.0 or newer have relaying disabled by default, so for those you’ll need to use the access database to enable individual hosts to relay. The general idea is simple. When a new incoming SMTP connection is received, sendmail retrieves the message header information and then consults the access database to see whether it should proceed to accept the body of the message itself. The access database is a collection of rules that describe what action should be taken for messages received from nominated hosts. The default access control file is called /etc/mail/access. The table has a simple format. Each line of the table contains an access rule. The lefthand side of each rule is a pattern used to match the sender of an incoming mail message. It may be a complete email address, a hostname, or an IP address. The righthand side is the action to take. There are five types of action you may configure. These are:

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

firewall is able to establish direct network connections

webmaster — Mon, 01 Oct 2007 18:04:46 +0000

firewall is able to establish direct network connections with hosts both on the private network and on the Internet. The smart host would accept mail from both hosts on the private network and the Internet, store them in local storage and then manage the retransmission of that mail to the correct host directly. Smart hosts are usually used when all other methods of delivery have failed. In the case of the organization with the private network, it would be perfectly reasonable to have the hosts attempt to deliver mail directly first, and if that fails then to send it to the smart host. This relieves the smart host of a lot of traffic because other hosts can directly send mail to other hosts on the private network. sendmail provides a simple method of configuring a smart host using the SMART_HOST feature; when implementing it in the Virtual Brewery configuration, we do exactly this. The relevant portions of our configuration that define the smart host are: define(`SMART_HOST’, `uucp-new:moria’) LOCAL_NET_CONFIG # This rule ensures that all local mail is delivered using the # smtp transport, everything else will go via the smart host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3 The SMART_HOST macro allows you to specify the host that should relay all outgoing mail that you are unable to deliver directly, and the mail transport protocol to use to talk to it. In our configuration we are using the uucp-new transport to UUCP host moria. If we wanted to configure sendmail to use an SMTP-based Smart Host, we would instead use something like: define(`SMART_HOST’, `mail.isp.net’) We don’t need to specify SMTP as the transport, as it is the default. Can you guess what the LOCAL_NET_CONFIG macro and the rewrite rule might be doing? The LOCAL_NET_CONFIG macro allows you to add raw sendmail rewrite rules to your configuration that define what mail should stay within the local mail system. In our example, we’ve used a rule that matches any email address where the host belongs to our domain (.$m.) and rewrite it so that it is sent directly to the SMTP mailer. This ensures that any message for a host on our local domain is directed immediately to the SMTP mailer and forwarded to that host, rather than falling through to our smart host, which is the default treatment. Managing Unwanted or Unsolicited Mail (Spam) If you’ve subscribed to a mailing list, published your email address on a web site, or posted an article to UseNet, you will most likely have begun to receive unsolicited advertising email. It is commonplace now for people to scour the net in search of email addresses to add to mailing lists that they then sell to companies seeking to advertise their products. This sort of mass-mailing behavior is commonly called spamming. The Free On-line Dictionary of Computing offers a mail-specific definition of spam as:[1] 2. (A narrowing of sense 1, above) To indiscrimately send large amounts of unsolicited e-mail meant to promote a product or service. Spam in this sense is sort of like the electronic equivalent of junk mail sent to “Occupant.” In the 1990s, with the rise in commercial awareness of the net, there are actually scumbags who offer spamming as a “service” to companies wishing to advertise on the net. They do this by

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

Details concerning mail aliases may be found in

webmaster — Mon, 01 Oct 2007 07:29:17 +0000

Details concerning mail aliases may be found in the aliases(5) manual page. A sample aliases file is shown in Example 18-4. Example 18-4. Sample aliases File # # The following two aliases must be present to be RFC-compliant. # It is important to resolve them to ‘a person’ who reads mail routinely. # postmaster: root # required entry MAILER-DAEMON: postmaster # required entry # # # demonstrate the common types of aliases # usenet: janet # alias for a person admin: joe,janet # alias for several people newspak-users: :include:/usr/lib/lists/newspak # read recipients from file changefeed: |/usr/local/lib/gup # alias that invokes program complaints: /var/log/complaints # alias writes mail to file # Whenever you update the /etc/aliases file, be sure to run the command: # /usr/bin/newaliases to rebuild the database that sendmail uses internally. The /usr/bin/newaliases command is a symbolic link to the sendmail executable, and when invoked this way, behaves exactly as though it were invoked as: # /usr/lib/sendmail -bi The newaliases command is an alternative and more convenient way to do this. Using a Smart Host Sometimes a host finds mail that it is unable to deliver directly to the desired remote host. It is often convenient to have a single host on a network take on the role of managing transmission of mail to remote hosts that are difficult to reach, rather than have each local host try to do this independently. There are a few good reasons to have a single host take on mail management. You can simplify management by having only one host with a comprehensive mail configuration that knows how to handle all of the different mail transport types, such as UUCP, Usenet, etc. All other hosts need only a single tranport protocol to send their mail to this central host. Hosts that fill this central mail routing and forwarding role are called smart hosts. If you have a smart host that will accept mail from you, you can send it mail of any sort and it will manage the routing and transmission of that mail to the desired remote destinations. Another good application for smart host configurations is to manage transmission of mail across a private firewall. An organization may elect to install a private IP network and use their own, unregistered IP addresses. The private network may be connected to the Internet through a firewall. Sending mail to and from hosts in the private network to the outside world using SMTP would not be possible in a conventional configuration because the hosts are not able to accept or establish direct network connections to hosts on the Internet. Instead, the organization could elect to have the firewall provide a mail smart host function. The smart host running on the

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

Linux Network Administrators Guide Prev Chapter 18. Sendmail

webmaster — Sun, 30 Sep 2007 19:27:42 +0000

Linux Network Administrators Guide Prev Chapter 18. Sendmail Next Some Useful sendmail Configurations There are myriad possible sendmail configurations. In this space we’ll illustrate just a few important types of configuration that will be useful in many sendmail installations. Trusting Users to Set the From: Field It is sometimes useful to overwrite the From: field of an outgoing mail message. Let’s say you have a web-based program that generates email. Normally the mail message would appear to come from the user who owned the web server process. We might want to specify some other source address so that the mail appears to have originated from some other user or address on that machine. sendmail provides a means of specifying which systems users are to be entrusted with the ability to do this. The use_ct_file feature enables the specification and use of a file that lists the names of trusted users. By default, a small number of system users are trusted by sendmail (root, for example). The default filename for this feature is /etc/mail/trusted-users in systems exploiting the /etc/mail/ configuration directory and /etc/sendmail.ct in those that don’t. You can specify the name and location of the file by overriding the confCT_FILE definition. Add FEATURE(use_ct_file) to your sendmail.mc file to enable the feature. Managing Mail Aliases Mail aliases are a powerful feature that enable mail to be directed to mailboxes that are alternate names for users or processes on a destination host. For example, it is common practice to have feedback or comments relating to a World Wide Web server to be directed to webmaster. Often there isn’t a user known as webmaster on the target machine, instead it is an alias of another system user. Another common use of mail aliases is exploited by mailing list server programs in which an alias directs incoming messages to the list server program for handling. The /etc/aliases file is where the aliases are stored. The sendmail program consults this file when determining how to handle an incoming mail message. If it finds an entry in this file matching the target user in the mail message, it redirects the message to wherever the entry describes. Specifically there are three things that aliases allow to happen: l They provide a shorthand or well-known name for mail to be addressed to in order to go to one or more persons. l They can invoke a program with the mail message as the input to the program. l They can send mail to a file. All systems require aliases for Postmaster and MAILER-DAEMON to be RFC-compliant. Always be extremely aware of security when defining aliases that invoke programs or write to programs, since sendmail generally runs with root permissions.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

terminated (Default: undefined). confSEPARATE_PROC (ForkEachJob) When processing the

webmaster — Sun, 30 Sep 2007 09:23:14 +0000

terminated (Default: undefined). confSEPARATE_PROC (ForkEachJob) When processing the mail queue and sending mail messages, sendmail processes one mail message at a time. When this option is enabled, sendmail will fork a new copy of itself for each message to be delivered. This is particularly useful when there are some mail messages that are stuck in the queue because of a problem with the target host (Default: false). confSMTP_LOGIN_MSG (SmtpGreetingMessage) Whenever a connection is made to sendmail, a greeting message is sent. By default, this message contains the hostname, name of the mail transfer agent, the sendmail version number, the local version number, and the current date. RFC821 specifies that the first word of the greeting should be the fully qualified domain name of the host, but the rest of the greeting can be configured however you please. You can specify sendmail macros here and they will be expanded when used. The only people who will see this message are suffering system administrators diagnosing mail delivery problems or strongly curious people interested in discovering how your machine is configured. You can relieve some of the tedium of their task by customizing the welcome message with some witticisms; be nice. The word EMSTP will be inserted between the first and second words by sendmail, as this is the signal to remote hosts that we support the ESMTP protocol (Default: $j Sendmail $v/$Z; $b). Prev Home Next Interpreting and Writing Rewrite Rules Up Some Useful sendmail Configurations

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

Linux Network Administrators Guide Prev Chapter 18. Sendmail

webmaster — Sat, 29 Sep 2007 22:20:05 +0000

Linux Network Administrators Guide Prev Chapter 18. Sendmail Next Configuring sendmail Options sendmail has a number of options that allow you to customize the way it performs certain tasks. There are a large number of these, so we’ve listed only a few of the more commonly used ones in the upcoming list. To configure any of these options, you may either define them in the m4 configuration file, which is the preferable method, or you may insert them directly into the sendmail.cf file. For example, if we wished to have sendmail fork a new job for each mail message to be delivered, we might add the following line to our m4 configuration file: define( confSEPARATE_PROC , true ) The corresponding sendmail.cf entry created is: O ForkEachJob=true The following list describes common sendmail m4 options (and sendmail.cf equivalents): confMIN_FREE_BLOCKS (MinFreeBlocks) There are occasions when a problem might prevent the immediate delivery of mail messages, causing messages to be queued in the mail spool. If your mail host processes large volumes of mail, it is possible for the mail spool to grow to such a size that it fills the filesystem supporting the spool. To prevent this, sendmail provides this option to specify the minimum number of free disk blocks that must exist before a mail message will be accepted. This allows you to ensure that sendmail never causes your spool filesystem to be filled (Default: 100). confME_TOO (MeToo) When a mail target such as an email alias is expanded, it is sometimes possible for the sender to appear in the recipient list. This option determines whether the originators of an email message will receive a copy if they appear in the expanded recipient list. Valid values are true and false (Default: false). confMAX_DAEMON_CHILDREN (MaxDaemonChildren) Whenever sendmail receives an SMTP connection from a remote host, it spawns a new copy of itself to deal with the incoming mail message. This way, it is possible for sendmail to be processing multiple incoming mail messages simulatanenously. While this is useful, each new copy of sendmail consumes memory in the host computer. If an unusually large number of incoming connections are received, by chance, because of a problem or a malicious attack, it is possible for sendmail daemons to consume all system memory. This option provides you with a means of limiting the maximum number of daemon children that will be spawned. When this number is reached, new connections are rejected until some of the existing children have

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

The $# metasymbol causes this rule to resolve

webmaster — Sat, 29 Sep 2007 11:13:46 +0000

The $# metasymbol causes this rule to resolve to a specific mailer, smtp in our case. The $@ resolves the target host. In our example, the target host is specified as $2.$m., which is the fully qualified domain name of the host on in our domain. The FQDN is constructed of the hostname component assigned to $2 from our lefthand side with our domain name (.$m.) appended. The $: metasymbol specifies the target user, which we again captured from the lefthand side and had stored in $1. We preserve the contents of the <> section, and any trailing text, using the data we collected from the lefthand side of the rule. Since this rule resolves to a mailer, the message is forwarded to the mailer for delivery. In our example, the message would be forwarded to the destination host using the SMTP protocol. Prev Home Next Generating the sendmail.cf File Up Configuring sendmail Options

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

LOCAL_RULE_1 and LOCAL_RULE_2 Ruleset 1 is applied to

webmaster — Fri, 28 Sep 2007 22:55:58 +0000

LOCAL_RULE_1 and LOCAL_RULE_2 Ruleset 1 is applied to all sender addresses and Ruleset 2 is applied to all recipient addresses. They are both usually empty. Interpreting the rule in our example Our sample in Example 18-3 uses the LOCAL_NET_CONFIG macro to declare a local rule that ensures that any mail within our domain is delivered directly using the smtp mailer. Now that we’ve looked at how rewrite rules are constructed, we will be able to understand how this rule works. Let’s take another look at it. Example 18-3. Rewrite Rule from vstout.uucpsmtp.m4 LOCAL_NET_CONFIG # This rule ensures that all local mail is delivered using the # smtp transport, everything else will go via the smart host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3 We know that the LOCAL_NET_CONFIG macro will cause the rule to be inserted somewhere near the end of ruleset 0, but before any smart host definition. We also know that ruleset 0 is the last ruleset to be executed and that it should resolve to a three-tuple specifying the mailer, user, and host. We can ignore the two comment lines; they don’t do anything useful. The rule itself is the line beginning with R. We know that the R is a sendmail command and that it adds this rule to the current ruleset, in this case ruleset 0. Let’s look at the lefthand side and the righthand side in turn. The lefthand side looks like: $* < @ $* .$m. > $*. Ruleset 0 expects < and > characters because it is fed by ruleset 3. Ruleset 3 converts addresses into a common form and to make parsing easier, it also places the host part of the mail address inside <>s. This rule matches any mail address that looks like: ‘DestUser < @ somehost.ourdomain. > Some Text’. That is, it matches mail for any user at any host within our domain. You will remember that the text matched by metasymbols on the lefthand side of a rewrite rule is assigned to macro definitions for use on the righthand side. In our example, the first $* matches all text from the start of the address until the < character. All of this text is assigned to $1 for use on the righthand side. Similarly the second $* in our rewrite rule is assigned to $2, and the last is assigned to $3.00 We now have enough to understand the lefthand side. This rule matches mail for any user at any host within our domain. It assigns the username to $1, the hostname to $2, and any trailing text to $3. The righthand side is then invoked to process these. Let's now look at what we're expecting to see outputed. The righthand side of our example rewrite rule looks like: $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3. When the righthand side of our ruleset is processed, each of the metasymbols are interpreted and relevant substitutions are made.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

A Simple Rule Pattern Example To better see

webmaster — Fri, 28 Sep 2007 11:06:24 +0000

A Simple Rule Pattern Example To better see how the macro substitution patterns operate, consider the following rule lefthand side: $* < $+ > This rule matches Zero or more tokens, followed by the < character, followed by one or more tokens, followed by the > character. If this rule were applied to brewer@vbrew.com or Head Brewer < >, the rule would not match. The first string would not match because it does not include a < character, and the second would fail because $+ matches one or more tokens and there are no tokens between the <> characters. In any case in which a rule does not match, the righthand side of the rule is not used. If the rule were applied to Head Brewer < brewer@vbrew.com >, the rule would match, and on the righthand side $1 would be substituted with Head Brewer and $2 would be substituted with brewer@vbrew.com. If the rule were applied to < brewer@vbrew.com > the rule would match because $* matches zero or more tokens, and on the righthand side $1 would be substituted with the empty string. Ruleset Semantics Each of the sendmail rulesets is called upon to perform a different task in mail processing. When you are writing rules, it is important to understand what each of the rulesets are expected to do. We’ll look at each of the rulesets that the m4 configuration scripts allow us to modify: LOCAL_RULE_3 Ruleset 3 is responsible for converting an address in an arbitrary format into a common format that sendmail will then process. The output format expected is the familiar looking local-part@host-domain-spec. Ruleset 3 should place the hostname part of the converted address inside the < and > characters to make parsing by later rulesets easier. Ruleset 3 is applied before sendmail does any other processing of an email address, so if you want sendmail to gateway mail from some system that uses some unusual address format, you should add a rule using the LOCAL_RULE_3 macro to convert addresses into the common format. LOCAL_RULE_0 and LOCAL_NET_CONFIG Ruleset 0 is applied to recipient addresses by sendmail after Ruleset 3. The LOCAL_NET_CONFIG macro causes rules to be inserted into the bottom half of Ruleset 0. Ruleset 0 is expected to perform the delivery of the message to the recipient, so it must resolve to a triple that specifies each of the mailer, host, and user. The rules will be placed before any smart host definition you may include, so if you add rules that resolve addresses appropriately, any address that matches a rule will not be handled by the smart host. This is how we handle the direct smtp for the users on our local LAN in our example.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services