> postfix. Then it's postfix's job to send the bounce back to > the end-user (iMail account). Postfix is doing it's job in > this situation, but it's sending a bounce message back to > iMail with a null sender address (mail from:<>). I don't know > why postfix is doing this. I'm sure I have a directive in my
To prevent loops. Lets say all the mailer daemons used some arbitrary address, and like many do they sent back so generic "You message was received by our administration" reply. Any bounce to an invalid address would trigger an infinite loop of mailer daemons shouting at each other. > main.cf that's causing this, but I have yet to find it. The reason for that is simple. Wietse is not willing to break the RFCs for the amusement of others. Personally I think that option in IMail was one of the stupidest things they ever did. They could have at least put huge warnings on it if nothing else. As it is, they encourage IMail admins to get black listed for refusing null senders. > Changing the directive in iMail to allow NULL senders seems > to have fixed this problem. I don't see that as a solution, > because I don't want to accept mail from NULL senders. Could Why not? It is the required way to send bounces. Heck, I bet you have been killing a bunch of bounces before putting in Postfix. You just never saw this because it was a remote issue. A black hole things disappeared into. It was only because this started happening to all bounces that caught your attention. So you could easily have been killing half the bounces before without even knowing it. > someone please help me figure out why postfix doesn't give a > valid mail from? When I look at the actual bounce message I > get back from iMail, it looks like there is a valid email > address in the mail from field. I've come to the conclusion > that iMail must append this. The mail from in the header shows > [EMAIL PROTECTED] but the logs show > that there is nothing in the mail from field. > > > Any ideas? Follow the RFCs for your own benefit. The Postfix box will kill enough mail so that in the end you will come out ahead. The RBLs, header checks, body checks, SAV, so on and so forth can easily kill most of the spam that does happen to use a null sender. --Eric
