On Mon, Mar 08, 2010 at 05:17:53PM +0000, Jaroslaw Grzabel wrote:
> /dev/rob0 pisze:
>>> local_recipient_maps = $alias_maps $virtual_mailbox_maps
>>> unix:passwd.byname
>>> local_transport = virtual
>>
>> Ugly! Do not mix classes like this.
>> http://www.postfix.org/ADDRESS_CLASS_README.html
>> Define your local domain class in mydestination (and take out the
>> above), and define your virtual mailbox class here:
>>
>>> virtual_mailbox_domains =
>>> mysql:/etc/postfix/mysql_virtual_domains_maps.cf
>>>
> I fixed that as you suggested.
Oops, sorry, perhaps I wasn't clear that the comments not related to
your immediate problem were intended as general comments, not as "do
this" advice in the context of this thread.
Your extremely complex setup is also extremely fragile.
>> Anyway, as per my WAG, this is probably where your issue lies:
>>> relocated_maps = mysql:/etc/postfix/mysql_relocated.cf
>>>
>> postmap -q problem.addr...@example.com mysql:/etc/postfix/mysql_relocated.cf
>>
>> This is probably returning the address you saw in your "user
>> relocated to ..." error.
>>
> Yes it returned that email address. But when I removed
> relocated_maps it bounces back with:
> user unknown. Command output: Invalid user specified.
You broke something in the pipe command.
>> Do carefully note the double use of the word, "probably". After I
>> advised you what we would need to see, you still have failed to post
>> the relevant logs.
>>
> Mar 8 16:59:25 [postfix/cleanup] 6F9442E60FD:
> message-id=<20100308155925.6f9442e6...@hostname>
I recently saw someone else using this type of syslogd, and I say, I
do not like it at all. My syslogd (the Linux one ported from old BSD
code, not sure where it's hosted) gives the PID of each logging
process, and in the case of Postfix, sometimes that is very
important.
Oops, that's just a rant, not a suggestion that you personally change
your syslogd. :) The PID is not important here, this time.
> Mar 8 16:59:25 [postfix/qmgr] 6F9442E60FD:
> from=<double-bou...@hostname>, size=278, nrcpt=1 (queue active)
> Mar 8 16:59:25 [postfix/pipe] 6F9442E60FD: to=<ja...@meil.me>,
> orig_to=<my_al...@meil.me>, relay=maildrop, delay=0.04,
> delays=0.02/0.01/0/0, dsn=2.0.0, status=deliverable (delivers to command:
> /usr/bin/maildrop)
Postfix delivers to maildrop via pipe(8). I don't know if that is
what was intended or not. This just says "status=deliverable", not
actually delivering to/through maildrop.
> Mar 8 16:59:25 [postfix/qmgr] 6F9442E60FD: removed
> Mar 8 16:59:28 [postfix/smtpd] 6D1912E60FD: client=X[XXX]
> Mar 8 16:59:28 [postfix/cleanup] 6D1912E60FD:
> message-id=<4b952006.7060...@x>
> Mar 8 16:59:28 [postfix/qmgr] 6D1912E60FD: from=<ja...@x>, size=818,
> nrcpt=1 (queue active)
> Mar 8 16:59:28 [postfix/smtpd] disconnect from X[X.110]
> Mar 8 16:59:28 [postfix/pipe] 6D1912E60FD: to=<my_al...@meil.me>,
> relay=maildrop, delay=3.1, delays=3.1/0/0/0.03, dsn=5.1.1, status=bounced
> (user unknown. Command output: Invalid user specified. )
Unfortunately, when the actual delivery is attempted, maildrop does
not know what to do with it. It's not logging here, and even if it
was, I've never used maildrop, so I can't help with that. (It's
off-topic here, as well.)
> Mar 8 16:59:28 [postfix/cleanup] 7C78B2E6114:
> message-id=<20100308155928.7c78b2e6...@hostname>
> Mar 8 16:59:28 [postfix/qmgr] 7C78B2E6114: from=<>, size=2654, nrcpt=1
> (queue active)
> Mar 8 16:59:28 [postfix/bounce] 6D1912E60FD: sender non-delivery
> notification: 7C78B2E6114
> Mar 8 16:59:28 [postfix/qmgr] 6D1912E60FD: removed
> Mar 8 16:59:29 [postfix/smtp] 7C78B2E6114: to=<ja...@x>,
> relay=newmail.X[X.110]:25, delay=0.72, delays=0.01/0.02/0.28/0.41,
> dsn=2.0.0, status=sent (250 ok 1268064272 qp 32176)
> Mar 8 16:59:29 [postfix/qmgr] 7C78B2E6114: removed
>
> When it used relocation maps:
> Mar 8 15:46:36 [postfix/smtpd] connect from X[X.110]
> Mar 8 15:46:36 [postfix/cleanup] B23092E60FD:
> message-id=<20100308144636.b23092e6...@hostname>
> Mar 8 15:46:36 [postfix/qmgr] B23092E60FD:
> from=<double-bou...@hostname>, size=278, nrcpt=1 (queue active)
> Mar 8 15:46:36 [postfix/pipe] B23092E60FD: to=<ja...@meil.me>,
> orig_to=<my_al...@meil.me>, relay=maildrop, delay=0.04,
> delays=0.02/0.02/0/0, dsn=2.0.0, status=deliverable (delivers to command:
> /usr/bin/maildrop)
> Mar 8 15:46:36 [postfix/qmgr] B23092E60FD: removed
> Mar 8 15:46:39 [postfix/smtpd] AFDD92E60FD: client=X[X.110]
> Mar 8 15:46:39 [postfix/cleanup] AFDD92E60FD:
> message-id=<4b950ef5.9030...@x>
> Mar 8 15:46:39 [postfix/qmgr] AFDD92E60FD: from=<ja...@x>, size=819,
> nrcpt=1 (queue active)
> Mar 8 15:46:39 [postfix/smtpd] disconnect from X[X.110]
> Mar 8 15:46:39 [postfix/error] AFDD92E60FD: to=<my_al...@meil.me>,
> relay=none, delay=3.2, delays=3.2/0.03/0/0.02, dsn=5.1.6, status=bounced
> (User has moved to ja...@meil.me)
I take it that this wasn't desired either.
> Thank you very much for your help and all advices. And you're
> right. As it's my private email and I have never had a time to
> configure it properly it's just a big mess created from dozen
> manuals.
None of which were the official project documentation. Private email?
Just one user, and you have virtual mailboxes and SQL transports?
Perhaps your best bet at this point is to start all over with
local(8) delivery as per this:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
Complex does not always mean better. Certainly not in the case of a
private email server. When you're handling dozens of domains for
hundreds of users, virtual(8) begins to make sense. When domain and
transport lists change frequently, SQL maps begin to make sense. I
know there are some folks who like all the complexity because it's
fun, but indeed, Rube Goldberg was fun. I'd hate to see a Goldberg
mail server, though. :)
> The other problem is that configuration hasn't been changed for
> ages but it was working I don't know... 5-6 months ago. Suddenly
> stopped. That's is what I cannot understand really.
I can't guess why, but as I said, a complex system is fragile. When
any of the component pieces changes it can fall apart. Some of your
pieces might even depend on DNS (which may or may not be under your
control.)
Again, sorry I steered you wrong with the general comments, which I
do stand behind, your current predicament notwithstanding.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
