Le 29/12/2010 20:18, Philip Van Pelt a écrit : > mouss schreef op wo 29-12-2010 om 20:01 [+0100]: >> Let me ask my question more precisely: is the _string_ after the '@' >> sign the same for both addresses? please note that I am not talking >> about delivery or virtual things. just the string. > > The domain (the _string_ after the @) is exactly the same for both > addresses. In fact that part of the log isn't redacted; I've set up a > test system to isolate the problem and I use "example.com" as my domain > so I don't interfere with my production system. > > [snip] >> Case 2) the domains are exactly the same. then you need to check why >> amavisd-new is not adding the headers. the amavisd-new list is a better >> place to get help. you can however check if there is anything special in >> your configuration (try with a new alias, ... etc). > > I'll try to look for help on that list as well. I just don't know if the > problem is situated in amavis; if I'm correct, it's not amavis that > translates the aliases. Amavis just passes this mail to postfix, who > rewrites the destination.
yes. and if you can't find a solution, you can chose to expand aliases before the filter instead of after the filter. just swap the corresponding receive_override_options. however, this means - amavis will no more see the original recipient. This may be ok though - if an alias expands to a lot of addresses, there'll be more overhead than when the expansion occurs at last. - if you rely on X-Original-stuff, it'll break > And as amavis is able to correctly flag the > first email, why shouldn't it do so with the alias? amavis correctly detected both messages as spam (look at "Passed SPAM"). either it added the Spam headers, in which case the problem is in your sieve; or it didn't add the headers and you need to figure out why. you'll need to check your amavisd-new configuration (including any database or other backend..). Good luck. > Or am I wrong on this one? >
