Put in remaining pages and wiki contents.
[ikiwiki.git] / docs / handbook / handbook-mail-trouble.mdwn
1 \r
2 \r
3 ## 20.5 Troubleshooting \r
4 \r
5 20.5.1. [mail-trouble.html#Q20.5.1. Why do I have to use the FQDN for hosts on my site?]:: 20.5.2. [mail-trouble.html#Q20.5.2.  **sendmail**  says ***`mail loops back to myself`***]:: 20.5.3. [mail-trouble.html#Q20.5.3. How can I run a mail server on a dial-up PPP host?]:: 20.5.4. [mail-trouble.html#Q20.5.4. Why do I keep getting ***`Relaying Denied`*** errors when sending mail from other hosts?]::\r
6 \r
7  **20.5.1.** Why do I have to use the FQDN for hosts on my site?\r
8 \r
9  **** You will probably find that the host is actually in a different domain; for example, if you are in `foo.bar.edu` and you wish to reach a host called `mumble` in the `bar.edu` domain, you will have to refer to it by the fully-qualified domain name, `mumble.bar.edu`, instead of just `mumble`.\r
10 \r
11 Traditionally, this was allowed by BSD BIND resolvers. However the current version of  **BIND**  that ships with DragonFly no longer provides default abbreviations for non-fully qualified domain names other than the domain you are in. So an unqualified host `mumble` must either be found as `mumble.foo.bar.edu`, or it will be searched for in the root domain.\r
12 \r
13 This is different from the previous behavior, where the search continued across `mumble.bar.edu`, and `mumble.edu`. Have a look at RFC 1535 for why this was considered bad practice, or even a security hole.\r
14 \r
15 As a good workaround, you can place the line:\r
16 \r
17     \r
18     search foo.bar.edu bar.edu\r
19 \r
20 \r
21  instead of the previous:\r
22 \r
23     \r
24     domain foo.bar.edu\r
25 \r
26 \r
27  into your `/etc/resolv.conf`. However, make sure that the search order does not go beyond the ***boundary between local and public administration***, as RFC 1535 calls it.\r
28 \r
29  **20.5.2.**  **sendmail**  says ***`mail loops back to myself`***\r
30 \r
31  **** This is answered in the  **sendmail**  FAQ as follows:\r
32 \r
33     \r
34     I'm getting these error messages:\r
35     \r
36     553 MX list for domain.net points back to relay.domain.net\r
37     554 <user@domain.net>... Local configuration error\r
38     \r
39     How can I solve this problem?\r
40     \r
41     You have asked mail to the domain (e.g., domain.net) to be\r
42     forwarded to a specific host (in this case, relay.domain.net)\r
43     by using an MX record, but the relay machine does not recognize\r
44     itself as domain.net. Add domain.net to /etc/mail/local-host-names\r
45     [known as /etc/sendmail.cw prior to version 8.10]\r
46     (if you are using FEATURE(use_cw_file)) or add ***Cw domain.net***\r
47     to /etc/mail/sendmail.cf.\r
48 \r
49 \r
50 The  **sendmail**  FAQ can be found at http://www.sendmail.org/faq/ and is recommended reading if you want to do any ***tweaking*** of your mail setup.\r
51 \r
52 ***'20.5.3. ***'How can I run a mail server on a dial-up PPP host?\r
53 \r
54  **** You want to connect a DragonFly box on a LAN to the Internet. The DragonFly box will be a mail gateway for the LAN. The PPP connection is non-dedicated.\r
55 \r
56 There are at least two ways to do this. One way is to use UUCP.\r
57 \r
58 Another way is to get a full-time Internet server to provide secondary MX services for your domain. For example, if your company's domain is `example.com` and your Internet service provider has set `example.net` up to provide secondary MX services to your domain:\r
59 \r
60     \r
61     example.com.          MX        10      example.com.\r
62                           MX        20      example.net.\r
63 \r
64 \r
65 Only one host should be specified as the final recipient (add `Cw example.com` in `/etc/mail/sendmail.cf` on `example.com`).\r
66 \r
67 When the sending `sendmail` is trying to deliver the mail it will try to connect to you (`example.com`) over the modem link. It will most likely time out because you are not online. The program  **sendmail**  will automatically deliver it to the secondary MX site, i.e. your Internet provider (`example.net`). The secondary MX site will then periodically try to connect to your host and deliver the mail to the primary MX host (`example.com`).\r
68 \r
69 You might want to use something like this as a login script:\r
70 \r
71     \r
72     #!/bin/sh\r
73     # Put me in /usr/local/bin/pppmyisp\r
74     ( sleep 60 ; /usr/sbin/sendmail -q ) &\r
75     /usr/sbin/ppp -direct pppmyisp\r
76 \r
77 \r
78 If you are going to create a separate login script for a user you could use `sendmail -qRexample.com` instead in the script above. This will force all mail in your queue for `example.com` to be processed immediately.\r
79 \r
80 A further refinement of the situation is as follows:\r
81 \r
82 Message stolen from the [FreeBSD Internet service provider's mailing list](http://lists.FreeBSD.org/mailman/listinfo/freebsd-isp).\r
83 \r
84     \r
85     > we provide the secondary MX for a customer. The customer connects to\r
86     > our services several times a day automatically to get the mails to\r
87     > his primary MX (We do not call his site when a mail for his domains\r
88     > arrived). Our sendmail sends the mailqueue every 30 minutes. At the\r
89     > moment he has to stay 30 minutes online to be sure that all mail is\r
90     > gone to the primary MX.\r
91     >\r
92     > Is there a command that would initiate sendmail to send all the mails\r
93     > now? The user has not root-privileges on our machine of course.\r
94     \r
95     In the ***privacy flags*** section of sendmail.cf, there is a\r
96     definition Opgoaway,restrictqrun\r
97     \r
98     Remove restrictqrun to allow non-root users to start the queue processing.\r
99     You might also like to rearrange the MXs. We are the 1st MX for our\r
100     customers like this, and we have defined:\r
101     \r
102     # If we are the best MX for a host, try directly instead of generating\r
103     # local config error.\r
104     OwTrue\r
105     \r
106     That way a remote site will deliver straight to you, without trying\r
107     the customer connection.  You then send to your customer.  Only works for\r
108     ***hosts***, so you need to get your customer to name their mail\r
109     machine ***customer.com*** as well as\r
110     ***hostname.customer.com*** in the DNS.  Just put an A record in\r
111     the DNS for ***customer.com***.\r
112 \r
113 \r
114  **20.5.4.** Why do I keep getting ***`Relaying Denied`*** errors when sending mail from other hosts?\r
115 \r
116  **** In default DragonFly installations,  **sendmail**  is configured to only send mail from the host it is running on. For example, if a POP server is available, then users will be able to check mail from school, work, or other remote locations but they still will not be able to send outgoing emails from outside locations. Typically, a few moments after the attempt, an email will be sent from  **MAILER-DAEMON**  with a ***`5.7 Relaying Denied`*** error message.\r
117 \r
118 There are several ways to get around this. The most straightforward solution is to put your ISP's address in a relay-domains file at `/etc/mail/relay-domains`. A quick way to do this would be:\r
119 \r
120     \r
121     # echo "your.isp.example.com" > /etc/mail/relay-domains\r
122 \r
123 \r
124 After creating or editing this file you must restart  **sendmail** . This works great if you are a server administrator and do not wish to send mail locally, or would like to use a point and click client/system on another machine or even another ISP. It is also very useful if you only have one or two email accounts set up. If there is a large number of addresses to add, you can simply open this file in your favorite text editor and then add the domains, one per line:\r
125 \r
126     \r
127     your.isp.example.com\r
128     other.isp.example.net\r
129     users-isp.example.org\r
130     www.example.org\r
131 \r
132 \r
133 Now any mail sent through your system, by any host in this list (provided the user has an account on your system), will succeed. This is a very nice way to allow users to send mail from your system remotely without allowing people to send SPAM through your system.\r
134 \r
135 \r
136 \r
137 CategoryHandbook\r
138 CategoryHandbook-email\r