Print

[cowboy]

Anti-sendmail post will be happily routed via /dev/null

As I've been going through full IPv6 setup for all my services (dns/krb/ldap/smtp....), I discovered that sendmail 8.14.3 (and below) have some issues on modern (2.6.xx) kernels and glibc (probably >= 2.3.3).

Its implementation of getaddrinfo fails to properly enumerate the extant interfaces, and their IPv6 addresses   Fortunately, this is going to be easy to fix, and hopefully soon there'll be new Debian/Ubuntu packages that handle this properly - maybe not before 8.14.4 is shipped, but still soon.

Note that AIX, and likely any other fairly modern Posix compliant systems may have similar problems (a few *BSD manpages seemed to imply this to be true).

[jimb]

What's the result of that?  Won't listen in IPv6 interfaces?  Any way you can force it via cmd line options or the CF file?

Obligatory "you could use Postfix/Exim/etc/etc".  At least you're not using netqmail like me.  It appears not to have any IPv6 support at all, except for some preliminary patches from an end user.    I plan to migrate my server over to something like Postfix.

[cowboy]

What's the result of that?  Won't listen in IPv6 interfaces?  Any way you can force it via cmd line options or the CF file?

It seems to listen, but doesn't recognize the IPv6 address as localhost equivalents, which can lead to suprising warnings -
'(may be forged)'.   I had email comming/going via ipv6 for a while (nothing recent, not sure why), so its more a cosmetic and ease of management issue.

Obligatory "you could use Postfix/Exim/etc/etc".  At least you're not using netqmail like me.  It appears not to have any IPv6 support at all, except for some preliminary patches from an end user.    I plan to migrate my server over to something like Postfix.

Hehe, as the Debian sendmail maintainer, that'd be rather odd...   (though I also - poorly - maintain the ldap-nss and pam-ldap packages that I'd like to deprecate in favour of libnss-ldapd - as that is what I now use).

Postfix is the only other MTA I'd consider, being that it also supports the milter interface and has a decent design - for the old-timer's amongst us, sendmail has changed alot since the 8.6|7|8 exploit dujour days.

I use sendmail, milter-greylist (I was a late convert to greylisting, despising the delay), mimedefang (to call spamassassin and clamav, and do some anti-spoofing, backscatter reduction, and filter-bypassing for daemons/authenticated users)... mimedefang gives you the full power (and, to some, horror) of perl.

[cowboy]

Oh, if you are running sendmail on Linux or AIX, and it does correctly recognize all your interfaces (ipv4 and ipv6), and all the address associated with them (meaning you don't need much of anything in /etc/mail/local-host-names),

Please let me know what version of sendmail, linux kernel, and libc6 you are running !

Thanks,

[jimb]

What's the result of that?  Won't listen in IPv6 interfaces?  Any way you can force it via cmd line options or the CF file?

It seems to listen, but doesn't recognize the IPv6 address as localhost equivalents, which can lead to suprising warnings -
'(may be forged)'.   I had email comming/going via ipv6 for a while (nothing recent, not sure why), so its more a cosmetic and ease of management issue.

Ah.  That's no biggy then.  Can probably just use one of the local equivalence files or set it in the .mc/.cf file manually if needed.

Obligatory "you could use Postfix/Exim/etc/etc".  At least you're not using netqmail like me.  It appears not to have any IPv6 support at all, except for some preliminary patches from an end user.    I plan to migrate my server over to something like Postfix.

Hehe, as the Debian sendmail maintainer, that'd be rather odd...   (though I also - poorly - maintain the ldap-nss and pam-ldap packages that I'd like to deprecate in favour of libnss-ldapd - as that is what I now use).

Postfix is the only other MTA I'd consider, being that it also supports the milter interface and has a decent design - for the old-timer's amongst us, sendmail has changed alot since the 8.6|7|8 exploit dujour days.

I use sendmail, milter-greylist (I was a late convert to greylisting, despising the delay), mimedefang (to call spamassassin and clamav, and do some anti-spoofing, backscatter reduction, and filter-bypassing for daemons/authenticated users)... mimedefang gives you the full power (and, to some, horror) of perl.

Ah.  Yeah I guess it's best to eat your own dogfood (or the upstream's)  

Postfix is pretty much what I was planning on going with.  Seems pretty well maintained, etc, although some MTAs have been around longer (Exim).

The only thing I do about spam ATM is using the Spamhaus Zen RBL.  Seems to block a very large percentage of spam, although if I were running a huge email shop I'd probably employ other methods as well.  RBL is really simple though, and works well enough for me.  

[cowboy]

The only thing I do about spam ATM is using the Spamhaus Zen RBL.  Seems to block a very large percentage of spam, although if I were running a huge email shop I'd probably employ other methods as well.  RBL is really simple though, and works well enough for me.  

I do use a select few DNSBLs to reject at SMTP time, and spamassassin will also use a few more - but only for scoring.  I'm a big fan of lots of tests, with fairly small scores.

I use sbl-xbl.spamhaus.org (probably because I lived for years on a dynamic PPOE line, but still ran a full-fledged mailserver that wasn't blacklist... those days are gone), bogusmx.rfc-ignorant.org, and dnsbl.dronebl.org.   Though, honestly, the last two so rarely catch anything above and beyond sbl-xbl that I could drop them and likely not notice

[snarked]

This must be some "debianism."  They like to mess with things - and in turn mess things up.

I run Sendmail 8.14.3, Linux 2.6.30.6 (.31 locks up; I filed a bug report, and 30.7 is out but I haven't compiled it yet), and my system is built usually from source for the critical services and originates from a Slackware release 10.1 for everything else.  IPv6 works just fine for me, with one exception:

If one uses the DAEMON_OPTION modifier=b, note that forwarding mail to systems that don't have IPv6 will hang in the queue until they time out.  It should abort with a "no route to host" error, but it doesn't.