(no subject)

I have re-read the WIKI and looked over my amavisd-maia logs.  There does not appear
to be any re-writing of the addresses, the recipient is listed as usernamedomain.com.
I have tried a few other settings including making the login name the usernamedomain.com.
All of the above appear to have no effect.  All of the spam and ham data is being sent to
the domain account or to .  We authenticate users against our postfix mySQL database.  Any 
additional recommendations?

Thank You.

craig carriere wrote:
>; I have amavisd-maia running on a SLES10 mail server using postfix 2.2
> and dovecot 1.0.  We recently converted our system to virtual users 
and
> domains with all of the postfix information stored in mySQL 
databases. 
> Everything is working fine except that I have noticed that ham from 
some
> users, both sent internally as well as external, are not being 
cached. 
> i reconfigured
 MM so  is set to catch mail for non-local users.  
Some
> of the users ham now appears in that system while others appear under
> their domain listing (for users in the same domain).  I must have
> something mis-configured but can not figure out what.  Anyone have a
> clue to point the clueless in the right direction?

If the mail is falling through to the . account, it's likely that
you've introduced an address-rewriting issue when you switched to
virtual users.  If Postfix is modifying the addresses it sends along to
amavisd-maia, they may no longer match the values in your users table,
so amavisd-maia isn't matching them correctly anymore--they fall 
through
either to the domain or . accounts as a result.  You might want to
review <http://www.maiamailguard.com/maia/wiki/Addresses> for a more
detailed look at the problem and some solutions.

- --
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamailguard.com/&gt;
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

craig carriere wrote:
> I have re-read the WIKI and looked over my amavisd-maia
logs.  There does not appear
> to be any re-writing of the addresses, the recipient is
listed as usernamedomain.com.
> I have tried a few other settings including making the
login name the usernamedomain.com.
> All of the above appear to have no effect.  All of the
spam and ham data is being sent to
> the domain account or to .  We authenticate users
against our postfix mySQL database.  Any 
> additional recommendations?

The fact that "all of the spam and ham data is being
sent to the domain
account or to ." means that there /is/ some
address-rewriting going on
between your upstream Postfix and amavisd-maia.

In other words, the recipient addresses that Postfix is
passing to
amavisd-maia don't match any of the addresses stored in your
'users'
table, so amavisd-maia tries to find a more approximate
match (the
domain account), and if even that fails, it resorts
to the . system
default account.

As a sanity check, take a look at your 'users' table,
checking the
'email' column to see if the recipient addresses
amavisd-maia is
receiving are found there.  If the amavisd-maia logs show
that mail was
received for 'userexample.com', does that address actually
exist as
such in the 'users' table?

If all else fails, you can turn up the $log_level in your
amavisd.conf
file to 3 or higher, restart amavisd-maia, and capture a
sample for me
to look over (send it to me off-list).  That said, I'm
pretty sure this
is still an address-rewriting issue, and the proper fix is
to delay the
aliasing until the downstream Postfix instance, so that
amavisd-maia
sees the original email addresses your users are expecting.

- --
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGW2YyGmqOER2NHewRAszAAJ9KLxcVmKod/wZ5tMsWq8QsVjekSgCf
UHKA
MnJ6CgxMzwOiuhpMeWJ7BOQ=
=Iv1g
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

(no subject)

Thread: (no subject)