All:
I'm seeing some odd behavior with the handling of socket code (sendto() functions) in tcpd/tcpd.c and the RFC1035 code. I'm actually seeing variations of the problem within and outside of a jail. Here's an example error message: May 6 17:38:06 drpmx courieresmtp: id=00073206.000000004A01DB63.0000B72F,from=<[email protected]>,addr=<[email protected]>: Can't assign requested address So the client SMTP and/or MX lookup code is having trouble creating a socket. My kernel/userland(libc) and Courier binaries are all compiled with V6 enabled. The system was recently upgrade to FreeBSD 7.2/amd64-RELEASE. At first I thought it was userland/kernel drift, but indeed everything is in sync. sysctl = net.inet6.ip6.v6only also seems to affect this bug $ sysctl -a| grep -i net.inet6.ip6.v6only net.inet6.ip6.v6only: 1 $ ktrace testmxlookup google.com Soft error. # sudo sysctl -w net.inet6.ip6.v6only=0 net.inet6.ip6.v6only: 1 -> 0 # ktrace testmxlookup google.com Domain google.com: Relay: smtp4.google.com, Priority: 10, Address: ::ffff:72.14.221.25 Relay: smtp2.google.com, Priority: 10, Address: ::ffff:64.233.165.25 Relay: smtp1.google.com, Priority: 10, Address: ::ffff:209.85.237.25 Relay: smtp3.google.com, Priority: 10, Address: ::ffff:209.85.137.25 Looking inside my kdump(8) of testmxlokoup: I see: 4366 testmxlookup CALL socket(PF_INET6,SOCK_DGRAM,IPPROTO_IP) 4366 testmxlookup RET socket 3 Then multiple failed calls of sendto(): 4366 testmxlookup CALL sendto(0x3,0x7fffffffe560,0x1c,0,0x7fffffffe770,0x1c) 4366 testmxlookup RET sendto -1 errno 22 Invalid argument 4366 testmxlookup CALL sendto(0x3,0x7fffffffe560,0x1c,0,0x7fffffffe770,0x1c) 4366 testmxlookup RET sendto -1 errno 22 Invalid argument 4366 testmxlookup CALL sendto(0x3,0x7fffffffe560,0x1c,0,0x7fffffffe770,0x1c) I started digging through the various library calls, but I get a little lost when we get into: rfc1035_mksocket() and mksockets() A couple of quick notes: - The system is dual-homed v4/v6 - DNS resolvers are v4-only - All MX destinations are v4 only - net.inet6.ip6.v6only=0 makes courier work outside of a jail, but has no impact inside the jail - I've tried every permutation of v4, v6, multi, single IPs within the jail. Configure Flags: /configure --disable-root-check --with-db=db --enable-syslog=1 --enable-use-flock --program-transform-name=s,^,, --enable-utf7-folder-encoding --enable-unicode --with-mailuser=courier --with-mailgroup=courier --with-mailuid=465 --with-mailgid=465 --with-etcdir=/usr/local/etc --sysconfdir=/usr/local/etc/courier --datadir=/usr/local/share/courier --libexecdir=/usr/local/libexec --localstatedir=/var/spool/courier --enable-mimetypes=/usr/local/etc/mime.types --enable-imageurl=/webmail --with-cachedir=/var/spool/webmail --with-cacheowner=pop --with-calendardir=/var/spool/calendar --with-transport=local esmtp dsn --with-default-maildrop=./Maildir --with-paranoid-smtpext --enable-workarounds-for-imap-client-bugs --cache-file=/var/ports/usr/ports/mail/courier/work/courier.cache --without-ldapaliasd --without-ispell --with-ipv6 --disable-autorenamesent --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd7.2 Very strange. What's making this hard to debug is: How can I run client SMTP delivery processes through ktrace(8) ? ~BAS ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
