Michael, > must be something obvious, but I have one install that is NOT putting > the X-Spam headers in. and sometimes not putting the X-Virus-Scanned > headers in. I am talking about inbound email. Clayton Keller wrote: > domains need to be included in @local_domains_maps > for this info to display, correct?
Correct for X-Spam-* header fields, recipient must be local indeed. However, this is not necessary for X-Virus-Scanned, which is inserted even for non-local recipients, provided the virus scan was actually performed (not bypassed). > also, if users.local is defined it has to be 'Y' or NULL. A NULL causes search to continue with statical lookup tables. An absence of a field 'local' is (the only) special case, it implies true if any record (except '@.') did match (see below). README_FILES/README.lookups : SQL LOOKUPS [...] The field value NULL is translated to Perl undef, which according to lookup rules implies that the next lookup table (if there are more) is to be tried. In plain words, NULL means "this table does not know the answer, try the next one". Further searching in this table (e.g. for more general defaults) is terminated. Boolean fields are usually represented as a single character (instead of an integer) to minimize storage. Characters N,n,F,f,0,NUL and SPACE represent false (0), any other character represents true. Trailing blanks are ignored. It is customary to use Y for true and N for false. [...] Special handling of optional SQL field 'users.local' A special shorthand is provided when SQL lookups are used: when a match for recipient address (or domain) is found in SQL tables (regardless of field values), the recipient is considered local, regardless of static @local_comains_acl or %local_domains lookup tables. This simplifies life when a large number of dynamically changing domains is hosted. To overrule this behaviour, add an explicit boolean field 'local' to table 'users' (missing field defaults to true, meaning record match implies the recipient is local; a NULL field 'local' is not special, it is interpreted as undef like other NULL fields, causing search to continue into other lookup tables). > (I think this is the problem: mark? could this be a perl 5.10.1 problem? > earlier versions (5.8.8, 5.8.9) knew that NULL was NULL? and not ''? > > the domain is local, but I don't think amavis thinks the user is local > anymore. this sql db returns NULL for 'select local from users where > email='[email protected]'). > all others do the same, but for some reason, NULL means NO to this install. Hmmm. > yep: > (00922-02) lookup [local_domains] => true, > "[email protected]" matches, result="1", > matching_key="greenwich-associates.com" Good. This should be an adequate proof that a recipient was local, regardless of what lookup mechanism provided this result. > Solved, sorta. not sure if this is a perl bug, or amavisd 2.6.4 bug, or > my bug. > > certain conditions, users.local would return NULL (I have a custom query) > for ME, users.local == N means not even accept email, Y then have a > custom policy, and NULL, they use the policy at id1. > > (the domain evaluated as local, so amavisd ran the right policies!), but > when it [came] time for 'do_tag' to happen, since users.local was NULL, > amavisd saw this as ! 'Y'. > it ran the tests, based on the sql lookups, but did everything but put > the headers in the outbound email Strange. A log level 5 may explain the situation. > (funny, they put the headers in the quarantined email!) Adding header fields to quarantined mail works independently, recipient need not be local for X-Spam-* to go into a quarantined mail. > (mark: isn't NULL the same as the field not being there? I know if the > users.local field is missing, you don't even evaluate it) Yes, a NULL or an absence of a field should have the same effect FOR ALL SQL FIELDS _EXCEPT_ 'LOCAL', search should continue with the next (if any) lookup table, e.g. with statical lookups. An absent field 'local' on an otherwise matched record implies true. Mark ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user Please visit http://www.ijs.si/software/amavisd/ regularly For administrativa requests please send email to rainer at openantivirus dot org
