Date: Sat, 04 Jan 2003 02:41:34 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Gary W. Swearingen" <swear@attbi.com> Cc: freebsd-current@freebsd.org Subject: Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay) Message-ID: <3E16BA5E.1FD866D1@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <c9622346-1e23-11d7-83f4-0002b32ee8e9@iv.nn.kiev.ua> <ihadihx3fq.dih_-_@localhost.localdomain> <3E163C0A.C0CF8146@mindspring.com> <8p4r8pwgl6.r8p@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
[ There is a genuine FreeBSD bug or two at the root of your problem ] "Gary W. Swearingen" wrote: > I guess you're saying IPv6 is a "sendmail" default and not a OS default; > "ping localhost" says it's pinging "127.0.0.1", not "::1". Ping is ICMP echo datagrams; it requires a different ping for IPv6 (different raw sockets). 8-). > I didn't see much IPv6 stuff (like a default choice) in the README > file, unsuprisingly. Nope. It's in or it's not, based on IPv6 capable interfaces being used, or IPv4 specific ones (gethostbyname vs. getaddrinfo, etc.). If it's IPv6 capable, IPv6 is always preferred. > BTW, I was suprised to find several help files only > under /usr/src and the Sendmail Installation and Operation only under > that and not yet built from the source "op.me". (PR worthy?) Like I said: the documentation is port. The book is for a relatively old version, and has not been updated for a very long time. Part of it is that Bryan Costales had started on an update, and then got off on other things. I don't know the current status, but your best information is going to come from the source tree .../sendmail/cf/README, and the source code itself. I don't think it's really "PR-worthy": everyone knows about it. > Why isn't "::1.in-addr.arpa." built into the resolver (or something) > like "1.0.0.127.in-addr.arpa." seems to be? (Rhetorical question.) This is actually a problem with your local DNS server not having the correct defaults. Basically, you need to claim that you are authoritative for the loopback interface for the in-addr.arpa. domain, which is is the domain in which reverse lookups (gethostbyaddr) occur. Basically, this means you set up an SOA record for 127.in-addr.arpa., and define host 1.0.0.127.in-addr.arpa. as having a reverse of "localhost". You need to do the same thing for IPv6. This happens a lot, when your DNS server is old, and you install a new IPv6 host, and don't add records to your DNS server for the IPv6 loopback and multicast. It happens because the library routines have a built-in preference for IPv6. > > You can "fix" this by disabling the DNS cross-check in the file > > sendmail.cf, and by getting rid of the peer name lookup in the > > loopback case. What you did with the IPv4 just took advanatage > > of the fact that the in-addr.arpa. IPv4 delegations existed, when > > the IPv6 loopback address ones did not. > > Repairing sendmail config rot only once or twice a year, I can barely > deal with the .mc file; I try to stay out of the .cf file. The .cf file is a generated file. You use M4 macros to change the settings, and then regenerate it with the Makefile down in the site config file directory where the sendmail.mc lives. > And in quite a lot of reading, I've not run across "cross-check" or > "peer name lookup" This is very simple. When a host connects, the sendmail server does a getpeername(3) to obtain the IP address of the machine which connected to it. It then does a gethostbyaddr(3) to do a peer name lookup... basically, given the IP address of the machine connecting to the server, it tries to obtain the canonical name of the connecting machine. It does this for logging purposes, and so that you can allow/deny relay, etc., by name. Then it looks up the IP address of the canonical name, to get a list of IP addresses for the machine. Then it verifies that the IP address of the peer that made the socket connection is one of the IP addresses in that list. By doing this, it cross-checks that the forward and reverse DNS mappings for the IP address match. This lets it make decisions on the basis of names, rather than IP addresses, for things like anti-SPAM rules, relaying, and so on. This is why if you tenet to an SMTP server, and tell it "HELO foo", it will "250 Hello" back at you with your real host name, or the IP address, if there's no reverse mapping, instead of calling you "foo": it doesn't believe what you told it. > or "loopback case" The "loopback case" is the case where a machine connects to itself. This happens in the new version of sendmail because the mail submission agent connects to the sendmail server, via MSP, using a network connection. This connection is most often over the loopback interface, via MSP (mail submission protocol). This is the value you tweaks to be "[127.0.0.1]". The default for this is "localhost", and, given your hosts file, the answer it will prefer is IPv6 instead of IPv4 (per the above, all clients that can talk both protocols will prefer IPv6, for forward compatability with wide-scale IPv6 deployment -- at some point in the future, IPv4 will be turned off and no longer be available on the Internet). The reason putting "[127.0.0.1]" worked for you is that, by putting brackets around the IPv4 address, you supressed the DNS lookup of the value in the brakets, and it treated it as an address... and it's an IPv4 address. Without you putting that there as the value for "msp", the default is "localhost", per the above. > or "delegations" There are two major DNS authorities. These are ".", for forward lookups, and ".in-addr.arpa.", for reverse lookups. A "delegation" is what determines whose DNS server is authoritative for a given suffix. If you look up an IP address, trying to get a reverse mapping to a name, what you are really looking up is a delegation of the .in-addr.arpa. domain for the IP address (reversed to put most significant value last, instead of first, so it can be treated as a suffix). If you look up a host name, then you are looking up a delegation of the . domain for the name. For example, the root of the Internet is ".". The ".com" domain is actually a delegation off this (the real name is ".com.") to a set of DNS servers that serve ".com" requests. Say you are looking up a host in IBM; then you go to ".", and get the delegation for ".com.", go to a different DNS server for that, and ask it for the DNS server for ".ibm.com.", and then you go to that DNS server and ask it for "www.ibm.com.", and it gives you an IP address back. Basically, authority for any given suffix is _delegated_, with the split at the ".", to some other DNS server. So if I have a host "foo.example.com A 192.168.1.12", then I end up with a delegation for the forward lookup from . to .com. to .example.com. for looking up "foo.example.com.", and I have *another* delegation from the NSP/ISP from . to .arpa. to .in-addr.arpa. to 192.in-addr.arpa. to 168.192.in-addr.arpa. Because these authorities are seperate, this means that if I do a reverse lookup and then a forward lookup, I'm checking with two different people, and if they match, then both people agree that the machine isn't lying to me. That's a crosscheck. Actually, sendmail and other programs that do crosschecks can probalbly be written to skip the check, if they know it's a loopback connection, but they don't. So the DNS lookups are tried, and the gethostbyaddr() times out in 90 seconds, in your case, because your DNS isn't set up correctly for IPv6. > and would be unlikely to determine the implementation of your > spec if I had. But don't bother explaining; you have better > things to do, I'm sure. Might as well get it in the archive, for the next person who needs to know... 8-). > I sounds like you have a better fix below anyway, and I'm happy > with my kludge. I do think I get the gist of what you're saying > about the DNS issues. You're kludge breaks as soon as the submitting machine is not the server machine (i.e. you start making MSP connections over your local network). You will have to kludge every client machine to specify the IPv4 address of the MSP machine the same way. When Microsoft supports IPv6 stateless autoconfiguration by default, in an upcoming release, then you will end up having to wait for 90 seconds for your Outlook clients to send their email (or at least the initial email, if MS does what they normally do, and violate the RFC by caching the failures for future requests). > My local DNS is the resolver and /etc/hosts with > ::1 localhost localhost.localdomain > 127.0.0.1 localhost localhost.localdomain Nope. Not used the way you think. The reverse lookup doesn't treat the hosts file as authoritative, when trying to index by IP. I'm not sure if this is just because it hates the "::1" shorthand, or if there's some deeper issue, but I think it's that there's a deeper issue here. > I'm not even caching. Nowhere to do your fix (outside C code), AFAIK. You need to set up a caching DNS server on the machine, specify it as your DNS server in your /etc/resolv.conf, and then set the forwarder to whatever DNS server you currently have in your resolv.conf, tun on forwarding, turn on caching, and then make it authoritative for 127.in-addr.arpa., and the equivalent for IPv6, and add reverse records. Then, when the reverse lookup for the IPv6 loopback address happens, instead of finding nothing, and taking 90 seconds to time out, it will find the right thing, and work, immediately. Technically, this is probably a bug in either the FreeBSD resolver library, or the default FreeBSD hosts file, or both. > Would I have had this problem in 4.7 with the GENERIC kernel? Should > the docs say that you must run at least a caching DNS server and say > that you must set up this "::1.in-addr.arpa." thing, in order to run > sendmail with the GENERIC (or any IPv6) kernel? Probably. More likely, you need the resolver library to understand the shorthand form of the IPv6 loopback address, when doing a reverse lookup, so if you specify that it looks in the hosts file and then in bind, that it actuallly finds the one you already have in the hosts file. Again: FreeBSD bug, either in library, default config, or both. [ Hold Expensive ] > Uh huh. I gathered that from my reading, and maybe I'll try that sort > of queuing someday. I'm off the net most of the time and have a gut > objection to a queue runner banging on a closed door so often and just > feel more comfortable with the simple "do-it-now" method. But it would > be nice to be able to "send" mail while offline, I suppose. The local delivery mailer is not marked expensive, so local delivery goes immediately. The "HoldExpensive" just means that it won't try to send or lookup mail that has to go via SMTP -- mail that isn't local -- until you do an explicit queue run. The queue runner doesn't bang it's head... it brings the link up, and does what it needs to do. But since it runs with a .cf generated from a different .mc, it has timeouts that make the DNS work, instead of failing before the link is established. Effectively, this means you get to schedule your outgoing mail, instead of having it go immediately, if you want to do that. If you don't have outgoing mail, nothing happens. So if you, say, run "sendmail -dq1h", then it will accumulate mail that's not local, and send it out, once an hour. You can also not run it in daemon mode, and do an explicit queue run (wrap it in a shell script), and run it from cron. This basically lets you control you link costs (say you pay more for connecting at peak hours, or you pay connection setup and teardown charges each time, because you are using a business line, or say you are in Japan, where it costs money to send packets). It's usually done as a way of saving money. If you weren't interested in that, I think you'd just dial in and leave the link up all the time, right? Then it wouldn't matter what kind of network connection you had. 8-). > Thanks for the info (both times), even if some of it went over my head. > :-) Most any time. 8-). If you need the specific DNS modifying options, I guess I could dig them out for you, instead of pointing you at the .../cf/README; they deal with not attempting to cannonize the name of the local interface, which is what causes DNS activity when sendmail first starts up, and when someone on a PC mail client like OutLook connects to it. This can be a pain, since some mail clients connect periodically to cache connections, which would mean your link stays up 24 hours a day, costing you money. Most likely, you will also want to turn off the "ident" query to the client machine, since most people turn that off and/or firewall that port, and all you get out of that is an extra timeout; you can turn this off by setting the ident timeout to '0'. Mail's a lot more complicated than most people think, and adding in IPv6 makes it even more complicated, especially since FreeBSD has some bad defaults in that area (and/or a resolver bug or two). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E16BA5E.1FD866D1>