[server-admins] Exim sender verification (and the difference a www. makes)

[Jonathan Marsden]

Now we have the sender verify timeouts cleaned up by removing
lists.dsbl.org (thanks Troy!), I have played some more with exim sender
verification on crosswire.org to try and understand why we are still
seeing log entries like:

> 2009-08-05 00:35:20 H=localhost.extremezone.com (www.crosswire.org)
> [127.0.0.1] F=<mailman-bounces at www.crosswire.org> rejected RCPT
> <scribe at crosswire.org>: Sender verify failed

in /var/log/exim/reject.log (which I can now read, which is most helpful!).

It turns out that this is happening because we also see:

> 2009-08-05 00:35:20 H=localhost.extremezone.com (www.crosswire.org)
> [127.0.0.1] sender verify fail for
> <mailman-bounces at www.crosswire.org>: Unknown user

So, now we need to figure out why exim thinks there is no emailable user
called mailman-bounces at www.crosswire.org

A quick test with exim -bvs shows that the culprit is the www. in the
domain part:

  jmarsden at crosswire:~$ echo mailman-bounces at crosswire.org |exim -bvs
  > mailman-bounces at crosswire.org verified
  >
  jmarsden at crosswire:~$ echo mailman-bounces at www.crosswire.org |exim -bvs
  > mailman-bounces at www.crosswire.org failed to verify: Unknown user
  >

However, things are not quite what they seem, because:

  jmarsden at www.crosswire.org:~$ echo foo at www.crosswire.org |exim -bvs
  > foo at www.crosswire.org failed to verify: Unknown user
  >
  jmarsden at www.crosswire.org:~$ echo foo at crosswire.org |exim -bvs
  > foo at crosswire.org failed to verify: Unknown user
  >

OK, why is that?  I'm not yet 100% sure... thoughts follow that may or
may not be helpful :)

It seems that /etc/mailman/mm_cfg.py is currently a symlink to the
default config file at /usr/lib/mailman/Mailman/mm_cfg.py

This file tries to get the DEFAULT_EMAIL_HOST by calling getfqdn() which
returns www.crosswire.org:

  jmarsden at crosswire:~$ python -c "from socket import getfqdn ;
 print getfqdn()"
  www.crosswire.org

In the past there were edits made to mm_cfg.py, as evidenced by a file
/etc/mailman/mm_cfg.py.diff dated 15 Dec 2009.  I can't help wondering
whether the "better" setup woud be for Mailman-related mail to come from
user at crosswire.org, not from user at www.crosswire.org by default?

Exim believes itself to be crosswire.org, per line 88 of
/etc/exim/exim.conf:

  primary_hostname = crosswire.org

Exim also thinks mailman uses just two domains, per line 30:

domainlist mm_domains=crosswire.org : bibletechnologieswg.org

So the exim mailman_transport router is only active for those two domains.

HOWEVER, Mailman believes itself to *be* www.crosswire.org, per the
getfqdn() call as outlined above.  This difference, I *think*, is what
is causing the sender verify to fail.

If I held the email pumpkin, I would be tempted to do (all on one line):

  sed -i.bak -e 's/^domainlist mm_domains=/domainlist
mm_domains=www.crosswire.org : /' /etc/exim/exim.conf

and restart exim.  I am fairly sure this will fix sender verification.

Stepping back slightly and looking for "lessons learned" here, I'd note
that host names should not generally reflect a service name, but be
independent of the services the machine runs.  So the host could be
maroon.crosswire.org or whatever name you pick (there is an RFC on
picking good hostnames, BTW, RFC 1178).  This allows services to migrate
to difference hosts as things scale up, and also helps avoid this sort
of issue, because you configure each service to use whatever alias that
service should use (www., or mail., or lists., or just the domain name,
or whatever).  Actual hostnames are normally supposed to be machine
identifiers, not service identifiers.

BTW, I'm about to go away for a few days vacation, with limited
Internet/email availability, so I'm unlikely to respond rapidly to email
until at least Tuesday 11th August.

Jonathan