3

I have different forwarding needs for different domains, which all point to my mail-server:

[email protected]   [email protected]
[email protected]   [email protected]
@example.com        mylocalaccount

This all works... However, some of these users wish to use the +-notation to give different vendors different addresses, such as user1+vendor@example.com. And this part is not working -- all such e-mails end up delivered to the catchall mylocalaccount instead of being forwarded properly.

How do I make [email protected] be forwarded to the same destination as [email protected]?

I tried adding entries like

user1+*@example.com    foo+%[email protected]

but that didn't fix the problem...

Here are the debug-traces:

Without the detail:

% sendmail -d60.5 -bv [email protected]
map_lookup(dequote, me, %0=me) => NOT FOUND (0)
map_lookup(dequote, g, %0=g) => NOT FOUND (0)
map_lookup(virtuser, [email protected], %[email protected], %1=g) => [email protected] (0)

... works.

With the detail:

% sendmail -d60.5 -bv [email protected]
map_lookup(dequote, me, %0=me) => NOT FOUND (0)
map_lookup(dequote, g+meow, %0=g+meow) => NOT FOUND (0)
map_lookup(virtuser, [email protected], %[email protected], %1=g+meow) => NOT FOUND (0)
map_lookup(virtuser, @example.com, %[email protected], %1=g+meow) => me (0)
map_lookup(dequote, me, %0=me) => NOT FOUND (0)
map_lookup(user, me, %0=me) => me<> (0)
[email protected]... deliverable: mailer local, user me

... does not work -- comes to the catch-all local account "me".

Improve this question

2 Answers 2

Reset to default
1

It seems that + is missing in OperatorChars in your sendmail.cf. It makes R lines in sedmail.cf see one token user+detail instead of three tokens user + detail.

sendmail.cf generated from sendmail.mc should set OperatorChars to .:%@!^/[]+ by default accoding to the bat book. It may be changed in mc file by defining confOPERATORS.

Check what is reported by grep OperatorChars /etc/mail/sendmail.cf

Improve this answer
4
  • You may be right -- for the last few years, sendmail was warning at start-up about Warning: OperatorChars is being redefined. Maybe, I need to address this. But I do not set them explicitly anywhere in the .mc-file -- so I'm not sure, how. Also, the +-delivery works for the real local users...
    – Mikhail T.
    Jul 30, 2017 at 14:15
  • Ok, I hand-edited the sendmail.cf to move the OperatorChars definition to the very beginning of the file. The above-mentioned warning is gone and the virtuser-delivery works! Much rejoicing, but how do I codify it in my sendmail.mc? Thanks!
    – Mikhail T.
    Jul 30, 2017 at 14:24
  • sendmail.cf generated from *.mc file should set OperatorChars right by default (with '+' included'). It seems that something is wrong with your sendmail.mc to sedmail.cf transition.
    – AnFi
    Jul 30, 2017 at 15:34
  • It does generate the default OperatorChars line -- but the line appears too late in the file for some reason. I added the line explicitly -- after the DOMAIN(generic), but before the first FEATURE -- and now things work! The warning about OperatorChars "being redefined" is still there (because the same line now appears twice), but it seems harmless.
    – Mikhail T.
    Aug 7, 2017 at 20:28
1

If you want to virtusertable to redirect with +detail preserved then try:

# use %2 if you want to strip EMPTY +detail ([email protected])
[email protected]   foo%[email protected]

Debug procedure
As root execute sendmail -d60.5 -bv [email protected].
It should trace map lookups including virtusertable map lookups.
Try sendmail -d21.12 -d60.5 -bv [email protected] if +detail is stripped before virtusertable lookups.

[email protected] by default should make sendmail look for the following virtusertable enries:

  1. [email protected]
  2. [email protected]
  3. user+*@example.com
  4. [email protected]
  5. [email protected]
  6. +*@example.com
  7. @example.com

[email protected] (plus present but detail empty) conducts lookups 1+3+4+6+7
[email protected] (no +detail present) condutcs lookups 4+7

Improve this answer
1
  • The -d21.12 part makes the output too much for inclusion here, I posted it online verbatim. Thanks!
    – Mikhail T.
    Jul 27, 2017 at 17:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .