@local_domains_maps doesn't work as expected, not needed?

[dmorton]

The amavisd.conf file supplied has this line:

@local_domains_maps = ( [".$mydomain"] );

But it doesn't work as expected for me... I turned on autocreate, sent a message to a new account. I had removed the domain default for @dgrmm.net, but had dgrmm.net in the $mydomain variable, which I would expect to call it a local address.

In all fairness, I think this config item should not be present; the definitive answer for whether an address is local should be if we have a database entry other than @. to handle it.

Besides removing this from the config file, there is a bunch of code in maia_autocreate_user() that can be removed, as it would be impossible to autocreate a nonlocal(@.) user.

[rjl]

There are a number of obsolete amavisd-new config items like that one, yes. Most of the *_maps() settings aren't needed in a Maia setup since those values are typically stored in SQL columns and rows. The thing to remember about amavisd-new is that it was designed to be very flexible--there are generally three or four different ways to achieve the same configuration, with or without SQL, with or without LDAP, etc. The *_maps() settings are a convenience for barebones (non-SQL) setups that need to hard-code user configs in the amavisd.conf file.

Maia users can get into trouble if they set some of these things in amavisd.conf as well as in SQL--that's a downfall of the amavisd-new flexibility philosophy: if there are three different ways to configure a given setting, there are nine potential ways to misconfigure that setting. If we wanted to get really draconian about it, we could rip out almost all the non-SQL configuration options from amavisd-maia, but it would have to be some very delicate surgery.

[dmorton]

commented out the line in amavisd.conf in [1111], but leaving ticket open to investigate the latter half of the ticket. Removing from 1.0.2 milestone.