On Mon, 10 Dec 2007 21:55:13 -0500, Sam Varshavchik wrote:

Sorry for the late response, I was doing what you suggested and ran into a bigger problem on the server because something happened right when I was trying to test the command you sent... all my emails suddenly were gone! I dont know what happened, but because I didn't have backups, I lost my job, then my wife divorced me because I lost my job and the bank repossessed my house so I've been living in the park and have had to panhandle to get enough to use the internet at kinkos to send you a reply.

But seriously now...I'm not sure how you expect that to get past address verification, but for giggles:

Dec 11 12:49:52 tern postfix/smtpd[24072]: NOQUEUE: reject: RCPT from user-11l4q1l.cable.mindspring.com[0.0.0.0]: 550 5.1.1 `touch /var/mail/ blah`@site.net: Recipient address rejected: User unknown in virtual mailbox table; from=<mic...@riseup.net> to=<`touch /var/mail blah`@site.net> proto=ESMTP helo=<[0.0.0.0]>

I suppose some systems don't have address verification so that would be bad. I've seen a number of people on mailing lists use this as a suggested way to handle the problem that we had. Its clearly a poor hack, but is there a more safe way to do this? If we dont do this then when maildrop attempts delivery to someone who is over quota we get a result code of 77 (and in some odd corner cases 75), which is considered a EX_TEMPFAIL by postfix and as a result the message is put in the deferred queue for a retry over and over again for 4 days before its returned. We dont want these messages queued up in our deferral queue because the number of people over quota ends up jamming the queue with more than it can process. So this script calls maildrop with the message information passed as arguments and then decides what to do based on the result code (since this is not configurable in maildrop).

Just to be sure this wrapper wasn't causing the + addresses to be dropped, I removed it and sent a test message and the same behavior was observed.

Not in our environment, even if it got past the address verification stage in the first postfix instance, the transport would fail to look up the appropriate back-end mail storage host because there is no user in our directory with that name which maps to a storage host, and even if there was, the transport on the backend maildrop servers wouldn't accept it either.

Yeah I got other problems too, but they aren't something I'm going to bug you with. :)