Gentoo handbook should clearly state that if the system has permanent only IPv6 address, the /etc/hosts entries should look like this: 2001:5C0:8FFF:FFFE:0:0:0:33AB kestrel kestrel.twibright.com 127.0.0.1 localhost kestrel Fetchmail chokes and it's impossible to retrieve any subsequent e-mails. One has to log in to the remote system (if possible at all) and manually delete the malformed spam. This already happened twice to me. If the 127.0.0.1 doesn't contain the "kestrel" (as suggested in code listing 18 on http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8), fetchmail will choke on malformed spam. The spam contained "santaclaus@%%DOMAIN%" as From and From: address. fetchmail then says "reading message clock@twin.jikos.cz:1 of 162 (765 header octets) fetchmail: SMTP error: 501 <santaclaus@%%DOMAIN%>: domain missing or malformed gethostbyname failed for kestrel" I suggest "tux" to be appended to the 127.0.0.1 entry in code listing 18. Reproducible: Always Steps to Reproduce: 1.Configure your system according to gentoo guide 2.Wait for malformed spam 3.Run fetchmail Actual Results: Fetchmail refuses to retrieve any e-mail coming after the malformed e-mail until the malformed e-mail is deleted from the remote server manually. Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1.50GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -mcpu=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalib alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl dga divx4linux dri dv dvd dvdread eds emboss encode esd exif fam ffmpeg fftw flac flash foomatic foomaticdb fortran ftp gd gdbm gif glut gnome gpm gstreamer gtk gtk2 guile icq imagemagick imap imlib ipv6 jabber jack java javascript jpeg kde ldap libcaca libg++ libwww live matroska mikmod ming mmap mmx mng motif mozilla mp3 mpeg mysql nas ncurses nls ogg oggvorbis opengl oss pam pdflib perl php png python qt quicktime readline real ruby samba sdl sharedmem shorten slang socks5 speex spell sse ssl svg svga tcltk tcpd tetex theora threads tiff tls truetype truetype-fonts type1-fonts unicode vorbis wifi win32codecs wmf xine xinerama xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
This looks like fetchmail bug, there's nothing wrong with the /etc/hosts example, AFAIK.
You say: "there's nothing wrong with the /etc/hosts example". Can you prove it?
I reported this problem to fetchmail and they say it's not a problem of fetchmail, but some misconfiguration. I did the configuration according to the gentoo guide so there must be a bug in gentoo guide.
(In reply to comment #0) > I suggest "tux" to be appended to the 127.0.0.1 entry in code listing 18. As "tux" is there in the handbook code listing (listing 14) now, I'm closing this bug.
