[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What is "Malformed privilege data"?

I've recently rebuilt my linux system with new glibc 2.1, kernel 2.2 and
egcs 1.1.1, and have had no real problems, except that zmailer is behaving
really strangely. When I use fetchmail to get my mail and send it into my
system, the router logs say "Malformed recipient privilege data!" and the
messages get deferred. But I have no problems that I can find sending mail
through other means--in fact, I can send messages to the same addresses as
in the deferred messages and they go through fine! But I can not send the 
deferred messages, even if I cut off the envelope and pipe them back to 

I have been completely unsuccessful if finding out what this error means. 
I looked in the documentation, and the router config files, but found no
references. I read throught the current list archive, and found some 4 or
so questions about "Malformed privilege data", but not one answer. I tried
turning on debugging info for the logger, and saw that it looks like
"good" messages have a 4th router field that says "g3" or "g4" and "bad"
messages have "g1" or "g2" and I looked in the source, and found the error
message, but it was in a mess of stuff that I don't really want to
decipher even as much as I have and I get different results when I try the
router interactively (4th field is always "default_attributes" unless the
address hist an alias, in which case I get a "g7" or something similar),
so I come back to the list.

Could someone tell me what this error means, and/or how I can go about
tracking down what is actually wrong? Everything else works, and I'm
pretty sure this is the same zmailer setup I was using before (not the
same setup _files_ of course, since there have been code changes).

Also, I have a message from error that got deferred, and it says
"malformed sender" as well as "malformed recipipient privilege data".
What's wrong with "error"? 

Oh, and this is for zmailer version 2.99.50-s11.

Thanks for _any_ help,
Robert Braddock