Alias expansion error

Hi,
[quote user=»davi.santos»]Hello everyone, I’m not sure if this is the right place, if not, i’m sorry, but here’s the problem.

When we try to send e-mail to a distlist, specifically 2 different s distlists, we had the error 4.6.0 alias expansion.
I checked before and some people say the problem is something related to number of virtual_alias_expansion_limit that is set to 1000, ok we set this to 10.000. we don’t have that much e-mails on our environment but still the problem persists.
As a matter of fact is a distlist with 6 other distlists inside, but it still don’t reach even 1000.
Any hint?
We run zimbra 8.0.6_GA_5922, on CentOS release 6.5(Final).
Thanks in advance.[/QUOTE]
To ensure the configuration, would you like to paste the result of the following command :

su - zimbra
postconf virtual_alias_expansion_limit

I got similar problem in the past with the following error message :
[QUOTE]

Dec 30 09:08:07 server postfix/cleanup[14443]: warning: A3BCD382A768: unreasonable virtual_alias_maps map expansion size for all-user@mydomain.co.id

[/QUOTE]
and successfully resolve the problem with :

su - zimbra
postconf -e virtual_alias_expansion_limit=3000
postfix stop
postfix start

You are not logged in. Please login or register.

# postconf -e virtual_alias_expansion_limit=2500
# service postfix reload

Generated in 0.006 seconds (63% PHP — 37% DB) with 8 queries

Hi All,

I am not able to send the mail to users. It says ‘temporary error returned by alias expansion: [mailto:ahcc_dr2@domain.com]’

root@dr-msgbe1 # telnet dr-msgbe1 25
Trying 10.1.2.33...
Connected to dr-msgbe1.domain.com.
Escape character is '^]'.
220 dr-msgbe1.domain.com -- Server ESMTP (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit))
ehlo
250-dr-msgbe1.domain.com
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-DSN
250-ENHANCEDSTATUSCODES
250-EXPN
250-HELP
250-XADR
250-XSTA
250-XCIR
250-XGEN
250-XLOOP 1E7506579BC59E5A73278D76D2203CCD
250-ETRN
250-NO-SOLICITING
250 SIZE 0
mail from: test_dr1@domain.com
250 2.5.0 Address Ok.
rcpt to: test_dr2@domain.com
451 4.0.0 temporary error returned by alias expansion: mailto:test_dr2@domain.com

I have set logging for tcp_local channel.

I see logs below:

07-Aug-2008 17:10:42.96 3f0e.5.3 tcp_intranet JE 0 17:test_dr1@domain.com 7:rfc822; 17:test_dr2@domain.com -1 0: 0: 7:mailsrv 0: 0: 2:'' 0: 72:451 4.0.0 temporary error returned by alias expansion: test_dr2@domain.com 4:SMTP -1
07-Aug-2008 17:10:42.96 3f0e.5.3 tcp_intranet JE 0 17:test_dr1@domain.com 7:rfc822; 17:test_dr1@domain.com -1 0: 0: 7:mailsrv 0: 0: 2:'' 0: 72:451 4.0.0 temporary error returned by alias expansion: test_dr1@domain.com 4:SMTP -1
07-Aug-2008 17:10:42.96 3f0e.5.3 tcp_intranet BE 0 17:test_dr1@domain.com 7:rfc822; 3:bye -1 0: 0: 7:mailsrv 0: 0: 2:'' 0: 41:500 5.5.1 Unknown command "bye" specified 4:SMTP -1
07-Aug-2008 17:15:00.52 3f0e.6.4 tcp_local + O 32:TCP|127.0.0.1|25|127.0.0.1|36983 4:SMTP

Any idea what’s wrong in configuration?

Thanks and Regards,
-Shashank

Edited by: shashankj on Aug 7, 2008 6:57 AM

Right now, half of our users are using Kerio 6.3, and the other half are using Exchange 2003. Kerio acts as the main MX server for all incoming mail. If the user is on Exchange, it forwards the mail over to Exchange. It works pretty well.

Lately, a few domains that are emailing use (qwest.net being one) get a bounced message that says «#5.3.0 SMTP; 550 5.3.0 Mailbox alias could not be expanded». The same message in the Kerio log looks like this: «Result: failed, Status: 5.1.8 501 5.5.4 Invalid Address».

I’ve done a lot of research, and it comes down to their email server being improperly configured.
http://support.microsoft.com/kb/291828

Every time I do a DNS check on an offending domain, it usually shows a warning under «Mail server host name in greeting».

I’ve performed KB 291828 from Microsoft on our Exchange server, which works if the person sends directly to the exchange server (ie <_a.t_>exchange.domain.com).

So what’s the deal with the Kerio server. Anyone have a guess on how to fix it?

Use a command other than version. Try aliasing l to log, for instance. (Or, as VonC notes, upgrade—it actually does work in modern Git. The alias handling seems to have been rewritten between 2.17.3 and 2.18.0.)

Why does l = log work, and yet v = version not?

This is a little tricky!

Most Git commands are—and at one point, all Git commands were—separate programs that are installed separately into a directory (or folder, if you prefer the term) full of «Git commands you can run». For instance, git log is actually implemented by a command spelled git-log, which is installed in a special directory / folder.

This directory / folder is not one you normally run commands from, though.

Back in the distant past, these Git commands—git-log, git-commit, git-add, git-diff, and so on—were all installed directly, and you ran them directly, by typing in git-something. This worked OK with bash’s autocompletion, in that you could type git-comTAB to get the commit command, or git-chTAB to get the checkout command. But over time, the number of Git commands grew (git-cherry and git-cherry-pick), and grew, and grew; and eventually even typing in the full command git-add wasn’t enough because there’s also git-add--interactive for instance, so the TAB completion basically completely stopped working.

A decision was made: Git wasn’t going to stop coming with 57 different commands—actually, it’s over 150 now—but instead, all these various implementation commands would be stuffed away into a place where they would not be all up in your face all the time. A single front end command, spelled git, would let you type in the command as an argument to the front-end git command: git com, then TAB: bash now has a list of allowed completions, and will only pick commit since that’s the only com that you would use, not the git-commit-tree or git-commit-graph back end programs that only scripts regularly use.

So: the front end git command knows how to find and run all the various back end implementations. By convention, most of them are in the git-core directory: run

git --exec-path

and the front end prints out the name of the place where all the back-end programs actually live. (You can look in there, and even run them out of there directly if you like, although these days the front end git command now sets up information that the back end commands may want.)

But what about git version? Well, now that you know that Git commands actually live in the git-core folder, wherever that may be on your system, I suggest you look in there. Where is the git-version program? You will find git-checkout in there, and git-log, and git-commit, and git-diff and many others, but you won’t find a git-version. There isn’t one.

The version command is built directly in to the front end. The aliases only work when invoking a back end command. So there is—or was, anyway—no way to alias version. (At some point, obviously post 2.9 and pre 2.24, the alias handling code was smartened up to check the front-end built-ins as well.)

There’s one more important thing to know

The front end git command does know about some common back end commands, but it doesn’t have a complete list of back end commands. Instead, when you type in git asdf or git rumplestiltskin or git helloworld—none of which are actual Git commands—it just sets things up as usual and then attempts to run git-asdf or git-rumplestiltskin or git-helloworld, while telling the system to look in the git-core directory. It doesn’t tell the system not to look in other directories.

This means you can write your own Git commands. If you want a git asdf, you can write your own git-asdf program, and put it anywhere so that running git-asdf succeeds. You can now run it using git asdf.

Why, you might wonder, would you want to do this? If you install git-asdf in your own personal bin or scripts folder, you can just run git-asdf. And indeed, you can do that. But when you have the front end run it, you’re run with special Git setup information provided. This gives you the ability to write your program as an sh (or bash) script and get direct access to various Git helpers. The main helper is called git-sh-setup and you invoke it by «sourcing» it, with . (POSIX) or source (bash):

#! /bin/sh
. git-sh-setup

This adds shell functions die and say and git_pager and require_clean_work_tree and more. If you set the shell variable OPTIONS_SPEC before sourcing git-sh-setup, it will parse arguments for you. Look at the script—it’s right there in the git-core directory—to see how to use it.

(Note that, like all things Git, it has grown over time. It has more functions now than it did in the days of Git 1.7, for instance. If you want something that backports to older versions of Git, clone the Git repository for Git, pick a compatibility level, and git checkout the old one to see what you can rely on.)

1 Sane solution

/etc/postfix/main.cf
   bounce_queue_lifetime = 0
   notify_classes = bounce
   bounce_notice_recipient = bounces@<yourdomain.tld>

• You may be tempted to disable bounce(8) service, but I expect that disables postmaster bounces.

For more details see the Drop undelivered MAILER-DAEMON and collect bounces in postfix

How it works:

1. Undeliverable bounce messages are deleted
2. A copy of all bounce messages is sent to bounces@<yourdomain.tld>

Drawbacks: 1) bounces@<yourdomain.tld> must be a non-redirected local inbox. 2) original bounce messages are deleted after the server attempts their useless delivery over the failed relay

2 Slightly Insane solution (untested)

/etc/postfix/main.cf
   sender_dependent_default_transport_maps = hash:sender_dependent_default_transport_maps
   virtual_mailbox_base = /var/spool/mail
   virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
   virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps
   virtual_gid_maps = static:<GID_of_/var/spool/mail>
   #virtual_mailbox_domains = <yourdomain.tld> #MAYBE

sender_dependent_default_transport_maps
   MAILER-DAEMON@<yourdomain.tld> virtual:

/etc/postfix/virtual_uid_maps
   alice@<yourdomain.tld>   1000
   bob@<yourdomain.tld>     1002
   charlie@<yourdomain.tld> 1001

/etc/postfix/virtual_mailbox_maps
   alice@<yourdomain.tld>    alice/
   bob@<yourdomain.tld>      bob
   charlie@<yourdomain.tld>  charlie

• Don’t forget to $postmap all *_maps files after every change.

For more details see the virtual delivery agent manpage and collect bounces in postfix

How it works:

1. sender_dependent_default_transport_maps forces bounce delivery by virtual: delivery agent …
2. … which delivers the message to mailbox/maildir configured in virtual_*_maps

Drawbacks: 1) Untested. 2) Will never deliver to UID below virtual_minimum_uid. 3) virtual_*_maps must be manually kept in sync with existing user accounts

3 fully Insane solution

/etc/postfix/main.cf
   virtual_mailbox_base = /var/spool/mail
   virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
   virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps
   virtual_gid_maps = static:<GID_of_/var/spool/mail>
   virtual_mailbox_domains = bounces.<yourdomain.tld>
   smtp_generic_maps = regexp:/etc/postfix/generic_maps
   sender_canonical_maps = regexp:/etc/postfix/canonical_sender_maps

/etc/postfix/virtual_uid_maps
   alice@bounces.<yourdomain.tld>   1000
   bob@bounces.<yourdomain.tld>     1002
   charlie@bounces.<yourdomain.tld> 1001

/etc/postfix/virtual_mailbox_maps
   alice@bounces.<yourdomain.tld>    alice/
   bob@bounces.<yourdomain.tld>      bob
   charlie@bounces.<yourdomain.tld>  charlie

/etc/postfix/generic_maps
   /@bounces./ @

/etc/postfix/canonical_sender_maps
   /^([^@]*)$/ $(1)@bounces.<yourdomain.tld>
   /^([^@]*)@/ $(1)@bounces.

• Don’t forget to $postmap all *_maps files after every change.

How it works:

1. canonical_sender_maps adds «bounces.» to senders of all locally queued mail
2. If a message goes out by SMTP, smtp_generic_maps undoes the change
3. If a message bounces, smtp_generic_maps does not apply …
4. … and notification is delivered to virtual domain @bounces.<yourdomain.tld>…
5. … which delivers the message to mailbox/maildir configured in virtual_*_maps

For more details see the address rewriting overview

Drawbacks: 1) Insane. 2) Will never deliver to UID below virtual_minimum_uid 3) virtual_*_maps must be manually kept in sync with existing user accounts