Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Terry Lambert <[EMAIL PROTECTED]> writes: > It's ugly, but try adding: > > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 localhost > localhost.localdomain That actually "fixed" it, but maybe for the wrong reason. I restarted my sendmail daemons for no good reason after changing config files and got this log: > Jan 4 18:46:16 localhost sm-mta[5812]: restarting /usr/sbin/sendmail due to signal ... > Jan 4 18:46:17 localhost sm-mta[5812]: gethostbyaddr(IPv6:::1) failed: 1 Then the mail processed normally (AFAIK) logging at the first send: > Jan 4 18:47:18 localhost sm-mta[6015]: h052lIt7006015: >from=<[EMAIL PROTECTED]>, size=477, class=0, nrcpts=1, >msgid=<[EMAIL PROTECTED]>, proto=ESMTP, >daemon=Daemon0, relay=localhost [127.0.0.1] where I expected to see [0.0...0.1] in that last "[]". Something didn't like the change to /etc/hosts and I suspect it gave up on IPv6 and resorted to IPv4. I X-buffer-copied this and counted the zeros: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 localhost localhost.localdomain I didn't get the "gethostbyaddr" error after changing /etc/hosts back and restarting the daemons. -- - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Terry Lambert <[EMAIL PROTECTED]> writes: > "Gary W. Swearingen" wrote: [...] > From my personal experience, DSL and cable modems are also transient > connections. 8-(. I've had real good service from both (in a hardware sense -- but at every "change of state" (initiated by me), their people would screw something up. After Qwest lied to me about DSL availability, costing me dearly in Apartment choice and cost, didn't bother to tell me about it until supposed hookup day, and then changed their mind after explaining why they couldn't do it, I went with AT&T for ISP AND phone service. They managed to hook the TV filter into my Internet line and tested it on the wrong side of the filter. Mananged to debug that myself because I didn't want to hear them say they didn't support non-MSFT OSes. > The RFC-correct name is > actually "link.local", not "localdomain", if you care, which you > probably don't. 8-). I could only find it in a draft, not a RFC: http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-dnsind-local-names-07.txt Google ignores the ".", making the search hard. I searched again on part of the title and author, but struck out. I found RFC-2606 with these new-to-me TLDs: test, example, invalid, and localhost. I guess it makes sense that the "localhost" domain can be the FQDN of the local host -- no need for two domain levels there. Do you propose changing /etc/hosts? Say, from 127.0.0.1 localhost localhost.my.domain to 127.0.0.1 localhost localhost.link.local or 127.0.0.1 localhost and why not 127.0.0.1 localhost localhost.site.local > Yes, it's annoying that the relationship between a caching DNS > forwarder and the DHCP assigned DNS server is not automatic in > FreeBSD clients, like it is in Windows clients. I've added that to my write-a-PR file, low on the list. > That's even easier: only do the queue run in the "linkup" script: > no head bumping at all. 8-). Now why didn't I think of that good idea? (Don't say!) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Gregory Neil Shapiro <[EMAIL PROTECTED]> writes: > swear> BTW, I was suprised to find several help files only under /usr/src > swear> and the Sendmail Installation and Operation only under that and not > swear> yet built from the source "op.me". (PR worthy?) > > op.me is built and installed in /usr/share/doc/smm/08.sendmailop/. > cf/README is installed as /usr/share/sendmail/cf/README. Thanks. Guess I shoulda examined a full "locate sendmail". :) The doc is the ASCII version. I've only seen the Postscript version before. The "missing help files" (under /usr/src/contrib/sendmail) include FAQ KNOWNBUGS README RELEASE_NOTES src/README src/SECURITY src/TRACEFLAGS src/TUNING > swear> Why isn't "::1.in-addr.arpa." built into the resolver (or something) > swear> like "1.0.0.127.in-addr.arpa." seems to be? (Rhetorical question.) > > The latest FreeBSD 4.7-STABLE /etc/namedb/named.conf contains: [...] > file "localhost-v6.rev"; [...] And the Handbook even tells you to how to create "localhost-v6.rev" (by running /etc/named/make-localhost) which is quite helpful, once you learn you need to to set up and run named to support the enabled-by- default sendmail. Thanks for the tip. Please excuse my sarcasm; your tip really was helpful in leading me to investigate /etc/named/* and then to the handbook to learn what make-localhost was about. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Hi,
> On Sat, 04 Jan 2003 12:47:29 -0800
> Terry Lambert <[EMAIL PROTECTED]> said:
tlambert2> The FreeBSD library bug is that the /etc/hosts file entry:
tlambert2> ::1
tlambert2> is not canonized before being compared, for the reverse lookup.
No, it does. I've tested it with following program:
#include
#include
#include
#include
#include
main()
{
struct sockaddr_in6 sin6;
struct hostent *ht;
int error;
char hbuf[NI_MAXHOST];
ht = gethostbyaddr((char *)&in6addr_loopback, sizeof(struct in6_addr),
AF_INET6);
if (!ht)
errx(1, "gethostbyaddr: lookup faild");
printf("gethostbyaddr: %s\n", ht->h_name);
ht = getipnodebyaddr((char *)&in6addr_loopback, sizeof(struct in6_addr),
AF_INET6, &error);
if (!ht)
errx(1, "getipnodebyaddr: lookup faild %d", error);
printf("getipnodebyaddr: %s\n", ht->h_name);
memset(&sin6, 0, sizeof(sin6));
memcpy(&sin6.sin6_addr, &in6addr_loopback, sizeof(struct in6_addr));
sin6.sin6_family = AF_INET6;
sin6.sin6_len = sizeof(sin6);
if (getnameinfo((struct sockaddr *)&sin6, sizeof(sin6),
hbuf, sizeof(hbuf), NULL, 0, 0) != 0)
errx(1, "getnameinfo: lookup faild");
printf("getnameinfo: %s\n", hbuf);
}
Then, it returned as expected:
ume@mille:1082% ./revtest
gethostbyaddr: localhost
getipnodebyaddr: localhost
getnameinfo: localhost
where my /etc/host.conf is:
hosts
#bind
and my /etc/hosts contains:
::1 localhost localhost.mahoroba.org
127.0.0.1 localhost localhost.mahoroba.org
When I commented the ::1 line out in /etc/hosts, the test program
returned:
me@mille:1087% ./revtest
revtest: gethostbyaddr: lookup faild
So, I cannot understand what you say.
tlambert2> It can probably be worked around by spcifying:
tlambert2> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
tlambert2> as the left hand side for the IPv6 loopback address, instead of ::1,
tlambert2> in the /etc/hosts file. I don't recommend this, since it would not
tlambert2> encourage the author of the IPv6 resovler code to fix the bug they
tlambert2> introduced.
You don't need to do it at all.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
"Gary W. Swearingen" wrote: > > 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). > > My ISP charges more for an Internet-connected LAN and I have no need for > one, so I don't bother. This brings to mind a common problem many of us > always have with free Unixy OSes; the developer/documenters tend to > ignore the many users who have no full-time Internet connection, local > DNS server, permanent domain names or IP address, or LAN. Of course, > we're pretty happy feeding off the crumbs of the big systems table. :) It's called an InterJet. 8-) 8-). >From my personal experience, DSL and cable modems are also transient connections. 8-(. > > > 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've never thought about it beyond the "localhost" case. So is > "/etc/hosts" obsolete (eg, for LAN hosts) if you need reverse lookup, > like if you want to use sendmail? It's ugly, but try adding: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 localhost localhost.localdomain The answer is probably that /etc/hosts is obsolete, and should probably be replaced by a caching local DNS server that's treated as authoritative for the local wire. The RFC-correct name is actually "link.local", not "localdomain", if you care, which you probably don't. 8-). > But I mentioned "/etc/hosts" mostly to point out that I'm using only the > non-server parts of "bind" which I called the "resolver" and that it > seemed to be doing reverse lookup on 127.0.0.1 (or have it hard coded). I think this is the library bug I mentioned earlier. I think that "::1" is not properly cannonized to convert it into the long form of "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1", before the compare happens, so the compare fails. > > 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. > > Easier said than done, of course. And there's the complication that my > forwarder info gets put in resolve.conf dynamically by DHCP. (But I > suspect it's stable enough for my purposes to hard code it in the named > files.) I think I'll live with my kludge for a while. Yes, it's annoying that the relationship between a caching DNS forwarder and the DHCP assigned DNS server is not automatic in FreeBSD clients, like it is in Windows clients. > > Technically, this is probably a bug in either the FreeBSD resolver > > library, or the default FreeBSD hosts file, or both. > > I'll try using the longhand version of "::1" (which I saw in another > message); I didn't know there were two versions. And I'll write a PR on > it, though if it's not a /etc/hosts problem, there's going to be too > much hand waving for a good chance of the PR being closed before it's > obsolete. That's my recommendation. > > The local delivery mailer is not marked expensive, so local > > delivery goes immediately. > > Unless it can't go immediately, in which case it's queued. If it can't go immediately, no matter what you do, it's going to be queued... so "no change". > > 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. > > The runner would bang its head trying to bring the link up on MY system > and I (currently) want it that way. That's even easier: only do the queue run in the "linkup" script: no head bumping at all. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Gregory Neil Shapiro wrote:
> The latest FreeBSD 4.7-STABLE /etc/namedb/named.conf contains:
>
> // RFC 3152
> zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
> type master;
> file "localhost-v6.rev";
> };
>
> // RFC 1886 -- deprecated
> zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
> type master;
> file "localhost-v6.rev";
> };
Which is what's missing in the DNS where the reverse lookup fails;
likely, it's a bug that FreeBSD does not come with a caching DNS
server enabled by default, out of the box.
The FreeBSD library bug is that the /etc/hosts file entry:
::1
is not canonized before being compared, for the reverse lookup.
It can probably be worked around by spcifying:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
as the left hand side for the IPv6 loopback address, instead of ::1,
in the /etc/hosts file. I don't recommend this, since it would not
encourage the author of the IPv6 resovler code to fix the bug they
introduced.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
[Dang; I meant to move this thread to -questions only, not -current.] Terry Lambert <[EMAIL PROTECTED]> writes: > [ There is a genuine FreeBSD bug or two at the root of your problem ] > > "Gary W. Swearingen" wrote: > > > 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. [...] And mine's 2nd edition from '97, but covers m4/.mc and still quite helpful, methinks. Someone's found were the ASCII version of "op" is hiding with an obfuscated name. But there's a SECURITY, TRACEFLAGS, TUNING, and a different README hiding under /usr/src (./contrib/sendmail/src/). (I think that there's quite a lot of documentation in src/../README-type files which should be brought out and indexed -- one of my many pipe dreams.) > > 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. It seems the real problem is that the FreeBSD installer sets up sendmail, while not setting up a DNS server (named_enable="NO"), which wouldn't be a problem if the resolver handled "::1.." like it does "1.0.0.127..." (with no DNS server). > 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. My DNS isn't set up correctly for IPv4, either, but THAT manages to work. (BTW, the time-out itself seemed to be 80 sec.) > Might as well get it in the archive, for the next person who > needs to know... 8-). I hope many people find it -- well done! Good descriptions of your terms. I'm keeping a copy of it with my sendmail notes. > 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). My ISP charges more for an Internet-connected LAN and I have no need for one, so I don't bother. This brings to mind a common problem many of us always have with free Unixy OSes; the developer/documenters tend to ignore the many users who have no full-time Internet connection, local DNS server, permanent domain names or IP address, or LAN. Of course, we're pretty happy feeding off the crumbs of the big systems table. :) > > 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've never thought about it beyond the "localhost" case. So is "/etc/hosts" obsolete (eg, for LAN hosts) if you need reverse lookup, like if you want to use sendmail? But I mentioned "/etc/hosts" mostly to point out that I'm using only the non-server parts of "bind" which I called the "resolver" and that it seemed to be doing reverse lookup on 127.0.0.1 (or have it hard coded). > > 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. Easier said than done, of course. And there's the complication that my forwarder info gets put in resolve.conf dynamically by DHCP. (But I suspect it's stable enough for my purposes to hard code it in the named files.) I think I'll live with my kludge for a while. > Technically, this is probably a bug in either the FreeBSD resolver > library, or the default FreeBSD hosts file, or both. I'll try using the longhand version of "::1" (which I saw in another message); I didn't know there were two versions. And I'll write a PR on it, though if it's not a /etc/hosts problem, there's going to be too much hand waving for a good chance of the PR being closed before it's obsolete. > [ 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.
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
swear> BTW, I was suprised to find several help files only under /usr/src
swear> and the Sendmail Installation and Operation only under that and not
swear> yet built from the source "op.me". (PR worthy?)
op.me is built and installed in /usr/share/doc/smm/08.sendmailop/.
cf/README is installed as /usr/share/sendmail/cf/README.
swear> Why isn't "::1.in-addr.arpa." built into the resolver (or something)
swear> like "1.0.0.127.in-addr.arpa." seems to be? (Rhetorical question.)
The latest FreeBSD 4.7-STABLE /etc/namedb/named.conf contains:
// RFC 3152
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
type master;
file "localhost-v6.rev";
};
// RFC 1886 -- deprecated
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
type master;
file "localhost-v6.rev";
};
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
[ 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 "loca
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Terry Lambert <[EMAIL PROTECTED]> writes: > The book is pretty useless. The reason the fix you are using > works is because you have an IPv6 connection by default, and by > explicitly specifying an IPv4 address, IPv4 is used. > > The issue here is the .in-addr.arpa. delegation for localhost > is considered to be local. When the getpeername() happens, it > gets an IPv6 address instead of an IPv4, and the the gethostbyaddr() > hangs looking for "::1.in-addr.arpa.", but has no problem finding > "1.0.0.127.in-addr.arpa.". 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". I didn't see much IPv6 stuff (like a default choice) in the README file, unsuprisingly. 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?) 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.) > 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. And in quite a lot of reading, I've not run across "cross-check" or "peer name lookup" or "loopback case" or "delegations" 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. 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. > > Is there a quick way to disable IPv6? While I figure that out or > > rebuild my kernel, I got a quick fix by changing, in my "submit.mc", > > this > > FEATURE(`msp') > > to this > > FEATURE(`msp',`[127.0.0.1]') > > This isn't the correct fix. The correct fix is to add an IPv6 address > and in-addr.arap. delegation for the loopback in your local DNS. My local DNS is the resolver and /etc/hosts with ::1 localhost localhost.localdomain 127.0.0.1 localhost localhost.localdomain I'm not even caching. Nowhere to do your fix (outside C code), AFAIK. 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? > As far as the HoldExpensive I recommended, the way you stated the > problem seemed to indicate that it was a failure to connect, not > a failure to validate a connection was going through. In general, > ou want to queue up any mail that can bring up a link, if your link > is transiently connected, and then control the link with a seperate > queue interval. The other DNS statements I made were to ensure that > the interface did not end up bouncing up when sendmail was started, > for local mail delivery, or for remote mail delivery, outside the > administratively controlled queueing intervals (which could be on > the order of seconds, if you wanted). 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. Thanks for the info (both times), even if some of it went over my head. :-) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
"Gary W. Swearingen" wrote: > Thanks. I tried that and some other things (eg service.switch). Even > read the book and help files some more. Terry's suggestion regarding > "expensive" seemed like the opposite of what I needed (I was trying to > keep the msg out of the queues) and I had no luck trying to disable some > DNS which he hinted at. > > I got my first good clue after adding level 15 logging to see an 80-sec > delay between MUA-launched sendmail and the MTA daemon. I then used > level-99 logging to find The book is pretty useless. The reason the fix you are using works is because you have an IPv6 connection by default, and by explicitly specifying an IPv4 address, IPv4 is used. The issue here is the .in-addr.arpa. delegation for localhost is considered to be local. When the getpeername() happens, it gets an IPv6 address instead of an IPv4, and the the gethostbyaddr() hangs looking for "::1.in-addr.arpa.", but has no problem finding "1.0.0.127.in-addr.arpa.". 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. > Is there a quick way to disable IPv6? While I figure that out or > rebuild my kernel, I got a quick fix by changing, in my "submit.mc", > this > FEATURE(`msp') > to this > FEATURE(`msp',`[127.0.0.1]') This isn't the correct fix. The correct fix is to add an IPv6 address and in-addr.arap. delegation for the loopback in your local DNS. As far as the HoldExpensive I recommended, the way you stated the problem seemed to indicate that it was a failure to connect, not a failure to validate a connection was going through. In general, ou want to queue up any mail that can bring up a link, if your link is transiently connected, and then control the link with a seperate queue interval. The other DNS statements I made were to ensure that the interface did not end up bouncing up when sendmail was started, for local mail delivery, or for remote mail delivery, outside the administratively controlled queueing intervals (which could be on the order of seconds, if you wanted). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
(cc'd to -questions, where I first post my problem, with no luck) Valentin Nechayev <[EMAIL PROTECTED]> writes: > I fix it with: > define(`confDIRECT_SUBMISSION_MODIFIERS',`CC u')dnl > For now I has no such problem at my home machine. > Yes, this solution isn't intuitive. Thanks. I tried that and some other things (eg service.switch). Even read the book and help files some more. Terry's suggestion regarding "expensive" seemed like the opposite of what I needed (I was trying to keep the msg out of the queues) and I had no luck trying to disable some DNS which he hinted at. I got my first good clue after adding level 15 logging to see an 80-sec delay between MUA-launched sendmail and the MTA daemon. I then used level-99 logging to find Jan 3 13:43:56 localhost sendmail[63611]: h03Lgf6p063607:\ makeconnection (localhost.localdomain. [IPv6:::1]) \ failed: Operation timed out with localhost.localdomain. I shoulda considered that one big config difference between my 4.7 config and 5.0 is custom kernel without IPv6 on 4.7 and still using GENERIC kernel with IPv6 on 5.0! I do have ::1 localhost localhost.localdomain in my /etc/hosts, but there's apparently something else wrong. Is there a quick way to disable IPv6? While I figure that out or rebuild my kernel, I got a quick fix by changing, in my "submit.mc", this FEATURE(`msp') to this FEATURE(`msp',`[127.0.0.1]') To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
