resolve virtual aliases from cmdline

[Matus UHLAR - fantomas]

Hello,

the postfix' sendmail -bv option has different usage than sendmail's -bv:

       -bv    Verify  names only - do not try to collect or deliver a message.
              Verify mode is normally used for  validating  users  or  mailing
              lists.

# sendmail -bv [hidden email]
[hidden email]... deliverable: mailer local, user xxx

The "sendmail -bv" can be used by spamass-milter to resolve destination
user and to use that users' spamassassin preferences:

     -x      Pass the recipient address through sendmail -bv, which will per‐
             form virtusertable and alias expansion.  The resulting username
             is then passed to spamc.  Requires the -u flag.  The spamass-mil‐
             ter configuration process does its best to find sendmail, but it
             is possible to override this compiled-in setting via the

     -- spamc flags ...
             Pass all remaining options to spamc.  This allows you to connect
             to a remote spamd with -d or -p.

Anyone's got an idea how to get this with postfix?

Postfix's "sendmail -bv" sends real mail to recipient.

only expanding virtual aliases should be fine.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

[Wietse Venema]

Matus UHLAR - fantomas:

> Hello,
>
> the postfix' sendmail -bv option has different usage than sendmail's -bv:
>
>        -bv    Verify  names only - do not try to collect or deliver a message.
>               Verify mode is normally used for  validating  users  or  mailing
>               lists.
>
> # sendmail -bv [hidden email]
> [hidden email]... deliverable: mailer local, user xxx

With Postfix, that is funndamentally not possible, because deliveries
happen asynchronously in the background.

I'll resist the temptation to harp on the security holes that I
elininated this way. OK, one: real Sendmail would import a hostile
LD_LIBRARY_PATH or LD_PRELOAD setting from a local attacker, and
would use that setting while it executed delivery to "|commmand"
in .forward files. This allowed a local attacker to execute commands
with the privileges of the recipient.

> The "sendmail -bv" can be used by spamass-milter to resolve destination
> user and to use that users' spamassassin preferences:
>
>      -x      Pass the recipient address through sendmail -bv, which will per?
>              form virtusertable and alias expansion.  The resulting username
>              is then passed to spamc.  Requires the -u flag.  The spamass-mil?
>              ter configuration process does its best to find sendmail, but it
>              is possible to override this compiled-in setting via the

Well that isn't going to work with Postfix. The sendmail emulation
can only go so far; if you want 100%, use real sendmail.

> only expanding virtual aliases should be fine.

The following:

(postmap -q [hidden email] maptype:mapname ||
    postmap -q @example.com)

will exit with status 0 (success) if a match was found.

It'll take more code to handle the third form: stripping an
address extension. Let me know if you need help.

        Wietse

[Wietse Venema]

Wietse Venema:

> > The "sendmail -bv" can be used by spamass-milter to resolve destination
> > user and to use that users' spamassassin preferences:
> >
> >      -x      Pass the recipient address through sendmail -bv, which will per?
> >              form virtusertable and alias expansion.  The resulting username
> >              is then passed to spamc.  Requires the -u flag.  The spamass-mil?
> >              ter configuration process does its best to find sendmail, but it
> >              is possible to override this compiled-in setting via the
>
> Well that isn't going to work with Postfix. The sendmail emulation
> can only go so far; if you want 100%, use real sendmail.
>
> > only expanding virtual aliases should be fine.
>
> The following:
>
> (postmap -q [hidden email] maptype:mapname ||
>     postmap -q @example.com)
>
> will exit with status 0 (success) if a match was found.
>
> It'll take more code to handle the third form: stripping an
> address extension. Let me know if you need help.

In the course of Postfix 3.x development I made the table lookup
sequences configurable internally, but haven't found the time to
expose that as main.cf settings. For that, the underlying code needs
to make fewer assumptions about how it will be used.

The idea is that given a full email address,

    postmap -q [hidden email] -m virtual_alias maptype:mapname

would query the table with the same sequence of full and partial
addresses as virtual_alias_maps, and thereby take some of the mystery
out of how Postfix works. I suppose it might be educational if postmap
can make its generated queries visible.

        Wietse

[Matus UHLAR - fantomas]

reviving old thread (hopefully I can get here now)

>> > The "sendmail -bv" can be used by spamass-milter to resolve destination
>> > user and to use that users' spamassassin preferences:
>> >
>> >      -x      Pass the recipient address through sendmail -bv, which will per?
>> >              form virtusertable and alias expansion.  The resulting username
>> >              is then passed to spamc.  Requires the -u flag.  The spamass-mil?
>> >              ter configuration process does its best to find sendmail, but it
>> >              is possible to override this compiled-in setting via the

>> > only expanding virtual aliases should be fine.

>Wietse Venema:
>> The following:
>>
>> (postmap -q [hidden email] maptype:mapname ||
>>     postmap -q @example.com)
>>
>> will exit with status 0 (success) if a match was found.
>>
>> It'll take more code to handle the third form: stripping an
>> address extension. Let me know if you need help.

On 28.08.20 14:30, Wietse Venema wrote:
>In the course of Postfix 3.x development I made the table lookup
>sequences configurable internally, but haven't found the time to
>expose that as main.cf settings. For that, the underlying code needs
>to make fewer assumptions about how it will be used.
>
>The idea is that given a full email address,
>
>    postmap -q [hidden email] -m virtual_alias maptype:mapname

-m enables mime parsing, perhaps you meant a new option?

>would query the table with the same sequence of full and partial
>addresses as virtual_alias_maps, and thereby take some of the mystery
>out of how Postfix works. I suppose it might be educational if postmap
>can make its generated queries visible.

That would be great, but IIUC, it's not available now.

I could probably do it using postconf to get virtual_alias_maps and
"postmap -q" to expand aliases. But I'd like to know order in which they are
expanded by postfix:

- do I need to query repeatedly, until virtual_alias_expansion_limit is
  reached?
  (postmap -q returns first query)

- how to repeat queries, if multiple lookup maps are used?
  Repeat first map until no expansions are made or cycle through all maps
  with all lookups?

thanks.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.

[Wietse Venema]

Matus UHLAR - fantomas:

> I could probably do it using postconf to get virtual_alias_maps and
> "postmap -q" to expand aliases. But I'd like to know order in which they are
> expanded by postfix:
>
> - do I need to query repeatedly, until virtual_alias_expansion_limit is
>   reached?
>   (postmap -q returns first query)
>
> - how to repeat queries, if multiple lookup maps are used?
>   Repeat first map until no expansions are made or cycle through all maps
>   with all lookups?

Postfix code works as follows:

    for each query pattern # user@domain, @domain, localpart, ...
        for each map in mumble_maps
            search the map for the query pattern

I left out the code that takes a search result and does something
depending on the query pattern that was matched (user@domain,
@domain, localpart, ...).

The reason for this arrangement of the two loops is that the query
patterns were generated by hand-crafted code, one iteration at a
time. We could change that with a data-driven approach, but it would
be incompatible with existing behavior.

        Wietse