26

Re: Catchall and plus addressing

This won't work.

This is current Postfix setting used by iRedMail:

virtual_alias_maps =
    proxy:ldap:/etc/postfix/ldap/virtual_alias_maps.cf,
    proxy:ldap:/etc/postfix/ldap/virtual_group_maps.cf,
    proxy:ldap:/etc/postfix/ldap/virtual_group_members_maps.cf,
    proxy:ldap:/etc/postfix/ldap/catchall_maps.cf

*) Problem #1: Postfix queries with these files in specified order, so if you return catch-all account in first file (virtual_alias_maps.cf), it will never use virtual_group_maps.cf and virtual_group_members_maps.cf. That means we don't have mailing list support with your modification.

*) Problem #2: recipient address is unknown if it's not an existing recipient, it might be 'john@', 'smith@', it never get a returned catch-all address with your modification, because '%s' in LDAP query files is full email address. And if you use '%d' (domain name) in query file, we have the same issue with current iRedMail setting (not modified), because '%d' always match with our catch-all account LDAP object (full dn: mail=@domain.com,ou=Users,domainName=domain.com,o=domains,dc=xx,dc=xx), so it will always return a catch-all address if someone sends email to 'user+ext@domain.com'.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

27

Re: Catchall and plus addressing

I don't think the problems you have raised are actually an issue. Here is what currently happens with the setup I've created.

For email address "test+1234@domain". Postfix does lookups as per "TABLE SEARCH ORDER" in http://www.postfix.org/virtual.8.html , so we start with "test+1234@domain"

1. Lookup against virtual_alias_maps... fails.
2. Lookup against group_maps... fails.
3. Lookup against group_members_maps... fails.
4. Lookup re-written to remove the extension, becoming test@domain
5. Lookup against virtual_alias_maps... success!

For a catch-all example, foo@domain

1. Lookup against virtual_alias_maps... fails.
2. Lookup against group_maps... fails.
3. Lookup against group_members_maps... fails.
4. Lookup re-written. No + extension, so skip to next form, which is just @domain
5. Lookup against virtual_alias_maps... success!

Even foo+bar@domain would work:

1. Lookup against virtual_alias_maps... fails.
2. Lookup against group_maps... fails.
3. Lookup against group_members_maps... fails.
4. Lookup re-written to foo@domain.
5. Lookup against virtual_alias_maps... fails.
6. Lookup against group_maps... fails.
7. Lookup against group_members_maps... fails.
8. Lookup re-written to @domain.
9. Lookup against virtual_alias_maps... success!

The trick is to not use %d ever in the lookups, and wait for postfix to retry in accordance with the search order that it uses.

Thinking this through, a cleaner solution, which would leave virtual_alias_maps unmodified, would be to change catchall_maps to the following:

query_filter    = (&(objectClass=mailUser)(accountStatus=active)(enabledService=catchall)(|(mail=@%s)(shadowAddress=@%s)))

The only required change is the two %d -> %s, but I've suggested adding an enabledService of catchall to distinguish the account from regular mail accounts.

I think this solution works for SQL and Postgres too, leaving address manipulation down to postfix, rather than the lookup script.

28

Re: Catchall and plus addressing

Any further thoughts on this? smile

29

Re: Catchall and plus addressing

What a surprise, it works for me.

I applied changes by following your post, and it works. tried to send email to (existing) full email address with/without '+ext' part, to mailing list account, to alias account, all work.

30

Re: Catchall and plus addressing

stevekez wrote:

The only required change is the two %d -> %s, but I've suggested adding an enabledService of catchall to distinguish the account from regular mail accounts.

Not necessary to use 'enabledService=catchall' in this case. In iRedMail, full dn of catch-all account is 'mail=@[domain],ou=Users,domainName=[domain],...], it's different than normal mail user (dn: mail=[username]@[domain],...).

stevekez wrote:

I think this solution works for SQL and Postgres too, leaving address manipulation down to postfix, rather than the lookup script.

I will keep current settings for SQL backends, but maybe your idea is better for SQL backends, need some more tests.

31

Re: Catchall and plus addressing

stevekez wrote:

I think this solution works for SQL and Postgres too, leaving address manipulation down to postfix, rather than the lookup script.

Tried with MySQL backend, it doesn't work. When send email to a non-existing email address, Postfix rejects the smtp session instead of mailing to catch-all address.

32

Re: Catchall and plus addressing

ZhangHuangbin wrote:

Not necessary to use 'enabledService=catchall' in this case. In iRedMail, full dn of catch-all account is 'mail=@[domain],ou=Users,domainName=[domain],...], it's different than normal mail user (dn: mail=[username]@[domain],...).

Great! I will post a final diff of my config here when I've successfully deployed into production, for the benefit of anyone else. Hopefully these will converge upon a future iRedMail release, but they should be small enough changes that they're easy to manage.

33

Re: Catchall and plus addressing

To fix this issue on old iRedMail release, just one command is enough:

# perl -pi -e 's#%d#%s#g' /etc/postfix/ldap/catchall_maps.cf

Then restart Postfix service.

34 (edited by stevekez 2015-06-03 16:01:03)

Re: Catchall and plus addressing

Excellent, but should that not be:

# perl -pi -e 's#@%d#%s#g' /etc/postfix/ldap/catchall_maps.cf

Otherwise the catchall lookup string will eventually be "@@domain"?

Edit: Yes, definitely; I get "unknown user" otherwise.

35

Re: Catchall and plus addressing

You're right, it's my mistake, sorry about this.
I repacked iRedMail-0.9.2, and fixed this in upgrade tutorial.