Hi Wietse,
I noticed an error in the patch. Attached you'll find the corrected version.
Thanks,
Roel
diff -pruN a/src/util/dict_union.c b/src/util/dict_union.c
--- a/src/util/dict_union.c 2014-10-21 01:53:04.0 +0200
+++ b/src/util/dict_union.c 2016-09-15 13:14:54.961550046 +020
Wietse Venema writes:
> while investigation unexpected bounces, I noticed that the unionmap did not
> handle errors of submaps properly. If a submap generated an error, the
> unionmap would not.
Cool. Can you also check how pipemap handles this case?
I checked and pipemap shows correct behavi
Hi,
while investigation unexpected bounces, I noticed that the unionmap did not
handle errors of submaps properly. If a submap generated an error, the
unionmap would not.
I tested this with an LDAP map, where the LDAP server was *not* reachable.
Configuring virtual_alias_maps as:
virtual_
Roel van Meer writes:
I was wondering if it is possible to return something (other than OK) on the
first pass, so the second lookup does not happen? So, something like DUNNO,
that prevents further lookups in the same map, and immediately continues in
the next map.
Ok, this is exactly
Hi list!
I'm trying to do some complicated things with a postfix access map, of the
regexp type:
...
check_client_access regexp:/etc/postfix/maps/client.regexp
...
When a connection is made, first the client hostname and then the client IP
address are looked up in the map. If on the f
Hi,
is it possible *in Postfix* to configure the list of users for whom smtp
auth is accepted?
I have smtp auth working, but I would like to exclude some accounts from
using this functionality. I know it could be done in the sasl plugins (as
documented in http://www.postfix.org/SASL_READM
Wietse Venema writes:
Dammit, I want to hear from people who expect to have problems
or not.
I don't expect problems on our systems because we also have set
append_dot_mydomain to no.
Furthermore, one of the great things about Postfix is its documentation, and
if the change is mentioned in
Viktor Dukhovni writes:
> If someone specifies multiple maps, each map is given the same
> query. When only some of the maps produce a result, what should
> the final result be:
>
> - The result is "not found". This is may be desirable in some cases.
> Right now, the virtual(8) daemon queries
Wietse Venema writes:
[join vs union]
I think there is something to be said for either name. It does not matter to
me, I think you should decide on a name, if you should choose to include
such functionality, to ensure it fits with Postfix's naming conventions
best.
That was a question
Wietse Venema writes:
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
Attached is the new patch. Sorry about the confusion.
This one has some documentation changes as well.
Thanks,
Roel
Add support for joinmap
Wietse Venema writes:
Unless I am mistaken, this implements the same functionality as the
pipemap table. It queries tables in sequence, not in parallel.
You are correct. The patch consisted of three parts. The first two parts are
used to get the basic file structure in place for the joinma
Roel van Meer writes:
What I am actually trying to do is a lookup with a single key in two maps.
Maybe stackmap or concatmap?
Now, if you specify two maps somewhere, and the first map returns a result,
there is no lookup done in the second map. With concatmap, both lookups
would happen
Wietse Venema writes:
> That would be overkill. I had thought something like:
> - The first map returns a result;
> - The second maps splits this result by newline or comma, does a lookup for
> each of the keys, concats this back together, and passes it on as the new
> result.
That would break
Wietse Venema writes:
> > Would it be difficult to extend the pipemap functionality so it does a
> > lookup in the second map for each of the results produced by the first
> > map?
>
> Unfortunately, yes. The Postfix dictionary abstraction is a simple
> key->value service, and has no notion of
Hi everyone,
I have a question about the new pipemap functionality that is in the 2.12
experimental release.
If I chain two lookup tables, and the first produces multiple results, it
seems the lookup in the second table is done with all of the results at once.
That means that the pipemap
Viktor Dukhovni writes:
> Basic question: if I have two virtual_mailbox_maps, is there a way
> to ensure lookups happen in both of them, even if the first already
> had a match?
No.
I was afraid it wouldn't.
> It seems the only way to make this work is to make sure that the LDAP
> lookup re
Hi list!
I'm in the process of converting our Postfix/OpenLDAP system to
Postfix/Samba 4/Zarafa. The OpenLDAP structure contained
mailacceptinggeneralid entries, with maildrop attributes for both local and
remote addresses. The problem is that this does not fit the Zarafa way.
Basic quest
Wietse Venema writes:
The submission service (port 587) requires authentication. The
ssmtp service (port 465) requires a protocol that has been deprecated
for years, and that is not even implemented in the Postfix SMTP
client.
So that kills off the STANDARD mail ports.
Ah, that's clear. Thank
Victor Duchovni writes:
This would be wrong. The "ssmtp" service, if it existed, is generally
for submission, not inbound MX delivery, and almost always requires
authentication, which you will not be able to provide. You would get
random rejection of your email if you guess random ports on the p
Hi list,
Does anyone know if it is possible to configure postfix in such a way that
it tries to deliver mail via ssmtp if delivery via smtp fails?
Background: We're operating a backup relayhost for a number of customers.
Their primary mail server is usually connected via adsl or cable. We're
20 matches
Mail list logo