On Thu, Jul 18, 2024 at 08:20:04AM -0700, Kenneth Porter via Postfix-users
wrote:
> On 7/18/2024 7:53 AM, Wietse Venema via Postfix-users wrote:
> > - Disable the recipient_delimiter feature, and use PCRE tables for
> >domain-dependent email address rewriting and routing.
&
On 7/18/2024 7:53 AM, Wietse Venema via Postfix-users wrote:
- Disable the recipient_delimiter feature, and use PCRE tables for
domain-dependent email address rewriting and routing.
PCRE sounds promising. It can't be any harder than writing a sendmail
rule! :D You can find the sen
ons:
- Disable the recipient_delimiter feature, and use PCRE tables for
domain-dependent email address rewriting and routing.
- Use separate Postfix instances (on separate IP addresses) for
domains with conflicting recipient_delimiter settings.
Note that recipient_delimiter is a set: "recipient_deli
Can I set recipient_delimiter to differerent values for different
domains I serve?
Many websites refuse a plus sign in an email address so I hacked my
sendmail config to allow dot to be translated to plus. I use that a lot
and have lots of plussed addresses in the wild that use a dot instead
"Matus" == Matus UHLAR <- fantomas > writes:
Matus> the latter can be disabled by calling check_recipient_access
Matus> "user+whate...@example.com REJECT"
This is what I want to achieve and after reading the documentation at
http://www.postfix.org/RESTRICTION_CLASS_README.html I got the picture.
> "Matus" == Matus UHLAR <- fantomas > writes:
Matus> the latter can be disabled by calling check_recipient_access
Matus> "user+whate...@example.com REJECT"
This is what I want to achieve and after reading the documentation at
http://www.postfix.org/RESTRICTION_CLASS_README.html I got the pi
suffix.
do you mean any accress containing the "+" or just the "+whatever" suffix?
the first should be doable by disabling recipient_delimiter so it's not
considered delimiter and/or special.
this way you still should be able to create users/aliases with the "+"
On 3/31/2022 1:21 PM, Togan Muftuolu wrote:
Hi,
As the subject says what is the best strategy or way to filter and in this
case I would rather reject specific mail addresses that are using the format
user+whate...@example.com
So in this case I would like to reject any mail that has the +wha
Hi,
As the subject says what is the best strategy or way to filter and in this
case I would rather reject specific mail addresses that are using the format
user+whate...@example.com
So in this case I would like to reject any mail that has the +whatever suffix.
My understanding is
- Relocated
On Sun, Nov 07, 2021 at 09:51:09PM +0100, Jeff Abrahamson wrote:
> > j...@p27.eu j...@p27.eu
>
> I added it to virtual, where it did not exist.
>
> > and make sure to remove (not include) "virtual" in:
> >
> > propagate_unmatched_extensions = canonical
> >
> > the default setting inc
>> Dovecot has the same setting: recipient_delimiter = +
>> In the logs, is the mail being rejected by postfix or by dovecot
>> after postfix tries to deliver?
> I'm not 100% sure: I suspect dovecot because the error occurs talking
> on the pipe to dovecot.
>
>
On 06/11/2021 23:34, Viktor Dukhovni wrote:
>> On 6 Nov 2021, at 3:43 pm, Jeff Abrahamson wrote:
>>
>> In main.cf I have set
>>
>> recipient_delimiter = +
>>
>> Reading the docs, I don't see anything else I ought to set for this to
>>
On Sat, Nov 06, 2021 at 07:00:12PM -0400, post...@ptld.com wrote:
> > My expectation is that dovecot is not involved in this issue, but I'm
> > not sure, so I mention anyway that that I have set
> >
> > virtual_transport = dovecot
>
>
> Dovecot has
> My expectation is that dovecot is not involved in this issue, but I'm
> not sure, so I mention anyway that that I have set
>
> virtual_transport = dovecot
Dovecot has the same setting: recipient_delimiter = +
In the logs, is the mail being rejected by postfix or by dove
> On 6 Nov 2021, at 3:43 pm, Jeff Abrahamson wrote:
>
> In main.cf I have set
>
> recipient_delimiter = +
>
> Reading the docs, I don't see anything else I ought to set for this to
> work: postfix should first try delivery to jeff+post...@p27.eu, then
>
I used to be able to receive mail at, for example,
jeff+post...@p27.eu. Such mail is now refused. I suspect this
behaviour changed when I upgraded postfix version some months back.
In main.cf I have set
recipient_delimiter = +
Reading the docs, I don't see anything else I ought to se
On 31.07.21 20:55, Wietse Venema wrote:
> Please also provide output from
>
> postconf -P
There is only syslog and submission stuff in postconf -P. The true
problem seems to have been that I didn't delete the verify_cache.db
after changing the virtual alias map.
- Florian.
Florian Hars:
> On 31.07.21 16:10, Florian Hars wrote:
> > I am currently slightly confused by the interaction between
> > recipient_delimiter and virtual_alias_maps.
>
> That interaction may actually not have been the true cause of my
> observations. What I now think happ
On 31.07.21 16:10, Florian Hars wrote:
> I am currently slightly confused by the interaction between
> recipient_delimiter and virtual_alias_maps.
That interaction may actually not have been the true cause of my
observations. What I now think happened is that the effects I observed
were cau
Please also provide output from
postconf -P
I suspect that you have virtual alias mapping disabled in some
message delivery path (with receive_override_options =
no_address_mappings).
Wietse
Hi,
I am currently slightly confused by the interaction between
recipient_delimiter and virtual_alias_maps. I have a test setup with
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_transport = lmtp:unix:private/dovecot-lmtp
a virtual domain "domain" an
On Sat, Aug 08, 2015 at 11:13:46PM +0200, Palica wrote:
> I have figured it out!
>
> This is the changed query:
>
> query = SELECT alias FROM (SELECT alias, 0 as priority FROM alias WHERE
> address='%s' AND active='1' UNION SELECT username as destination, 1 as
> priority FROM mailbox WHERE usern
my problem. I wanted to enable catchall address for a
virtualdomain to gather some spam to train my dspam. I used an address
with recipient_delimiter to recieve the messages (something like
someone+s...@domain.tld). I like to use the recipient_delimiter
addresses for other purposes as well, but
gather some spam to train my dspam. I used an address
with recipient_delimiter to recieve the messages (something like
someone+s...@domain.tld). I like to use the recipient_delimiter
addresses for other purposes as well, but when a lookup is made for
someone+someth...@domain.tld (some...@domain.tld
On 28 Sep 2014, at 09:14 , Wietse Venema wrote:
> When the recipient_delimiter set contains multiple characters (Postfix
> 2.11 and later), a [name] is separated from its extension
> by the first character that matches the recipient_delimiter set.
Thanks, I hadn’t found that
LuKreme:
> Is there documentation on how recipient_delimiter is treated in 2.11 if there
> is more than one delimiter defined?
>
> recipient_delimiter = +-_
>
> if an email comes to foo-bar_fee+...@domain.tld, is the precedence
> left to right from the definition, r
Is there documentation on how recipient_delimiter is treated in 2.11 if there
is more than one delimiter defined?
recipient_delimiter = +-_
if an email comes to foo-bar_fee+...@domain.tld, is the precedence left to
right from the definition, right to left from the definition, first match in
restarted postfix afterwards):
recipient_delimiter = +
Anecdotal reporting is useless. Only "postconf -n" output is
believed here. If you have a multi-instance Postfix environment,
check the correct instance. If mail traverses multiple instances,
make sure each is configured corre
On Wed, Jan 22, 2014 at 04:59:25PM +0100, Patrick Lists wrote:
> On a CentOS 6.5 box with a virtual_mailbox_domains,
> virtual_mailbox_maps, virtual_alias_maps setup all accessing
> openldap I added in main.cf (and restarted postfix afterwards):
>
> recipient_delimiter = +
Anec
Hi,
On a CentOS 6.5 box with a virtual_mailbox_domains,
virtual_mailbox_maps, virtual_alias_maps setup all accessing openldap I
added in main.cf (and restarted postfix afterwards):
recipient_delimiter = +
with the goal to get patrick+...@example.org working. Unfortunately
there is a
Jeroen Geilman:
> On 04/05/2013 08:17 PM, Wietse Venema wrote:
> > /dev/rob0:
> >>
> >> Thanks. A very minor complaint is that you have always been very
> >> consistent IIRC regarding plural and singular in parameter names, but
> >> now "recipie
On 04/05/2013 08:17 PM, Wietse Venema wrote:
/dev/rob0:
Thanks. A very minor complaint is that you have always been very
consistent IIRC regarding plural and singular in parameter names, but
now "recipient_delimiter" can be multiple characters. :) (I do
Yes and no. Postfix still sup
hi. i've briefly reviewed some of this posted work and it seems reasonable.
and refreshing to see work come from my simple query. so give the new
option a go as best seen fit! thanks.
he result is below.
> > Comments are welcome.
>
> Thanks. A very minor complaint is that you have always been very
> consistent IIRC regarding plural and singular in parameter names, but
> now "recipient_delimiter" can be multiple characters. :) (I do
Yes and no. Postfix s
and validates addresses
> via relay_recipient_maps, may forward mail via SMTP to downstream
> destinations which handle a subset (possibly none) of the supported
> extensions. This can create bouncebacks.
This problem is old: it exists whether or not recipient_delimiter
specifies a single c
hanks. A very minor complaint is that you have always been very
consistent IIRC regarding plural and singular in parameter names, but
now "recipient_delimiter" can be multiple characters. :) (I do
understand why it works better in this case; just saying, maybe for
naming consideration in
On Fri, Apr 05, 2013 at 09:23:42AM -0400, Wietse Venema wrote:
> Wietse Venema:
> > I've done a proof-of-concept implementation that works as documented
> > below the signature.
>
> I was able to simplify this further. The result is below.
> Comments are welcome.
One issue this does not discuss
ult setting:
forward_path = $home/.forward${recipient_delimiter}${extension},
$home/.forward
When Postfix expands this while delivering mail, it now replaces
${recipient_delimiter} with the actual recipient delimiter in the
recipient email address, instead of using the ma
I've done a proof-of-concept implementation that works as documented
below the signature.
This retains the old recipient_delimiter parameter because that
parameter has been in use since 19981029 in the forward_path default
parameter value, and I can't have a multi-character value
; (basically, replacing strchr() with strcspn()).
>
> This would allow one to use '-' for some websites and '+' for others.
Unfortunately this would break existing code that expands
$recipient_delimiter, for example the forward_path default value.
This means using a n
Kris Deugau:
> grarpamp wrote:
> > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
> > meta issue. Other users migration or dual uses aside, with that
> > one I wanted to but did not have benefit to research whether
> > + or - had better merits. Such as which is in more common u
grarpamp wrote:
> I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
> meta issue. Other users migration or dual uses aside, with that
> one I wanted to but did not have benefit to research whether
> + or - had better merits. Such as which is in more common use now,
> which is tren
> also note that the word used here, delimiter, is singular. There's a
The current form is known, these are just ideas put out there.
> Having migrated from + to - (reversed my polarity, I guess) I felt
I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
meta issue. Other users m
/dev/rob0:
> On Wed, Apr 03, 2013 at 04:27:30PM -0400, grarpamp wrote:
> > Is there a facility or ways to configure postfix to
> > recognize and process multiple recipient_delimiter
> > address extensions?
> No. As documented recipient_delimiter is a single character. Plea
On Wed, Apr 03, 2013 at 04:27:30PM -0400, grarpamp wrote:
> Is there a facility or ways to configure postfix to
> recognize and process multiple recipient_delimiter
> address extensions?
>
> ie: recipient_delimiter = +, -
No. As documented recipient_delimiter is a single characte
Is there a facility or ways to configure postfix to
recognize and process multiple recipient_delimiter
address extensions?
ie: recipient_delimiter = +, -
There could be some interpretations and implementations
of this with recipient_delimiter_method = ...
a) 'all', treat all the cha
r and .forward.
>
> And it mentioned local(8) immediately before that. Isn't that the kind
> of delivery we're talking about? Or is that a layer inbetween?
Perhaps you mean the text in the postconf(5) manpage (which also
appears in the stock main.cf file).
recipient_delimiter
ing
> user and .forward.
That's from postconf(5) recipient_delimiter, btw, and it does look
confusing to me, what is the intended meaning wrt user+foo and user here?
Also the log entry says this:
> Dec 15 17:59:09 mailhost postfix/local[7486]: B4D124341:
> to=, relay=local, dela
On 12/16/2012 01:22 AM, Wietse Venema wrote:
> decoder:
>> Hello Wietse,
>>
>> the documentation on this (the comment in the main.cf file also) says
>> that foo-test will first be checked and only if that doesn't exist it
>> will use foo. Is the documentation wrong then?
> Which comment? I don't re
decoder:
> Hello Wietse,
>
> the documentation on this (the comment in the main.cf file also) says
> that foo-test will first be checked and only if that doesn't exist it
> will use foo. Is the documentation wrong then?
Which comment? I don't recall that Postfix documentation promises
this for UN
hough it exists, please read it again carefully.
Best,
Chris
On 12/16/2012 01:08 AM, Wietse Venema wrote:
> decoder:
>> Hello,
>>
>>
>> today, we stumbled across a possible bug with the recipient_delimiter
>> option. Steps to reproduce are:
>>
>&
decoder:
> Hello,
>
>
> today, we stumbled across a possible bug with the recipient_delimiter
> option. Steps to reproduce are:
>
>
> 1. Set recipient_delimiter to - (minus sign), instead of the typical + sign.
> 2. Create a local system user with a - sign, e.g. foo-
Hello,
today, we stumbled across a possible bug with the recipient_delimiter
option. Steps to reproduce are:
1. Set recipient_delimiter to - (minus sign), instead of the typical + sign.
2. Create a local system user with a - sign, e.g. foo-test.
3. Send mail to foo-test@mailhost
Postfix will
Thanks !
Em 11/12/2011, às 17:46, Wietse Venema escreveu:
> Jose Renato Attab Braga:
>> Hi
>> I need use the address aaa+xyz@domain when I have the only the
>> address aaa@domain.
>> In my main.cf I have recipient_delimiter = +.
>> I use Mysql to emails adress
Jose Renato Attab Braga:
> Hi
> I need use the address aaa+xyz@domain when I have the only the
> address aaa@domain.
> In my main.cf I have recipient_delimiter = +.
> I use Mysql to emails adress and domains.
> What do I need to configurate this?
In Postfix, nothing. Postfix wi
Hi
I need use the address aaa+xyz@domain when I have the only the address
aaa@domain.
In my main.cf I have recipient_delimiter = +.
I use Mysql to emails adress and domains.
What do I need to configurate this?
Thanks
My main.cf
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
On 03/31/2011 08:41 AM, Corey Quinn wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 30, 2011, at 2:08 PM, Noel Jones wrote:
On 3/30/2011 3:53 PM, Ansgar Wiechers wrote:
On 2011-03-30 Corey Quinn wrote:
On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 30, 2011, at 2:08 PM, Noel Jones wrote:
> On 3/30/2011 3:53 PM, Ansgar Wiechers wrote:
>> On 2011-03-30 Corey Quinn wrote:
>>> On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
# main.cf
smtp_generic_maps =
regexp:/etc/postfix/ge
On 3/30/2011 3:53 PM, Ansgar Wiechers wrote:
On 2011-03-30 Corey Quinn wrote:
On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
# main.cf
smtp_generic_maps =
regexp:/etc/postfix/generic.regexp
# generic.regexp
IF /+.*@example\.com$/
/^(.*)+/ $1...@example.com
ENDIF
Threw this verbatim into
On 2011-03-30 Corey Quinn wrote:
> On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
>> # main.cf
>> smtp_generic_maps =
>> regexp:/etc/postfix/generic.regexp
>>
>> # generic.regexp
>> IF /+.*@example\.com$/
>> /^(.*)+/ $1...@example.com
>> ENDIF
>
> Threw this verbatim into my generic.regexp:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 30, 2011, at 1:29 PM, Wietse Venema wrote:
> Corey Quinn:
>> On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
>>>
>>> # main.cf
>>> smtp_generic_maps =
>>> regexp:/etc/postfix/generic.regexp
>>>
>>> # generic.regexp
>>> IF /+.*@example\.com$/
On Wed, Mar 30, 2011 at 02:46:39PM -0500, Noel Jones wrote:
> That's a very different problem, ie. strip recipient delimiters from mail
> relayed externally.
>
> Sounds as if smtp_generic_maps will fill the need.
> http://www.postfix.org/ADDRESS_REWRITING_README.html#generic
>
>
> # main.cf
> smt
Corey Quinn:
> On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
> >
> > # main.cf
> > smtp_generic_maps =
> > regexp:/etc/postfix/generic.regexp
> >
> > # generic.regexp
> > IF /+.*@example\.com$/
Remove the initial "+" character.
Wietse
On Mar 30, 2011, at 12:46 PM, Noel Jones wrote:
>
> # main.cf
> smtp_generic_maps =
> regexp:/etc/postfix/generic.regexp
>
> # generic.regexp
> IF /+.*@example\.com$/
> /^(.*)+/ $1...@example.com
> ENDIF
Threw this verbatim into my generic.regexp:
[root@mx1 postfix]# postmap -q "user+t...@ex
On 3/30/2011 2:13 PM, Corey Quinn wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 30, 2011, at 9:35 AM, Clayton Keller wrote:
I would like to allow the use of the recipient_delimiter, but rewrite the
address to ensure that it is delivered to the original address.
i.e. clay+t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 30, 2011, at 9:35 AM, Clayton Keller wrote:
> I would like to allow the use of the recipient_delimiter, but rewrite the
> address to ensure that it is delivered to the original address.
>
> i.e. clay+t...@domain.tld -> c...@
On Wed, Mar 30, 2011 at 11:54:32AM -0500, Clayton Keller wrote:
>> # Identity virtual alias mappings for all users that
>> # don't already have other alias entries.
>> #
>> c...@example.comc...@example.com
>> ...
>>
>
> I thought about that as well. However
On 03/30/2011 11:43 AM, Victor Duchovni wrote:
On Wed, Mar 30, 2011 at 11:35:03AM -0500, Clayton Keller wrote:
I would like to allow the use of the recipient_delimiter, but rewrite the
address to ensure that it is delivered to the original address.
i.e. clay+t...@domain.tld ->
On Wed, Mar 30, 2011 at 11:35:03AM -0500, Clayton Keller wrote:
> I would like to allow the use of the recipient_delimiter, but rewrite the
> address to ensure that it is delivered to the original address.
>
> i.e. clay+t...@domain.tld -> c...@domain.tld
>
> I would like th
I would like to allow the use of the recipient_delimiter, but rewrite
the address to ensure that it is delivered to the original address.
i.e. clay+t...@domain.tld -> c...@domain.tld
I would like this to be available to all addresses we accept mail for.
To do so I have been testing a reg
On Wed, Feb 02, 2011 at 09:36:52PM +0100, Andy Spiegl wrote:
> > the postconf command doesn't show "custom" variables, and
> > {foobar}_destination_recipient_limit is a custom var.
> Oh, I see.
>
> > It's up to you. as far as your return a DSN, be it "relayed" or
> > "delivered", I'd say it's ok.
> the postconf command doesn't show "custom" variables, and
> {foobar}_destination_recipient_limit is a custom var.
Oh, I see.
> It's up to you. as far as your return a DSN, be it "relayed" or
> "delivered", I'd say it's ok. DSN seems to cause lot of debates. so
> let's not get into that trap!
:-)
Le 02/02/2011 16:55, Andy Spiegl a écrit :
>> dovecot_destination_recipient_limit = 1
> I had this option in main.conf already.
> Why did "postconf -n" not list it? Not even "postconf" does, uhm...
>
the postconf command doesn't show "custom" variables, and
{foobar}_destination_recipient_limit i
> dovecot_destination_recipient_limit = 1
I had this option in main.conf already.
Why did "postconf -n" not list it? Not even "postconf" does, uhm...
> if it still doesn't work, tell us how you defined the "dovecot"
> transport? is it a pipe based transport in master.cf?
Exactly.
dovecot unix
Le 31/01/2011 12:50, Andy Spiegl a écrit :
> [snip]
>> do you expand your aliases before a content_filter? ... etc.
> I still have a very basic postfix setup.
try after adding
dovecot_destination_recipient_limit = 1
if it still doesn't work, tell us how you defined the "dovecot"
transport? is it
faces = all
inet_protocols = all
mailbox_size_limit = 0
mydestination = localhost,.XXXX.eu
myhostname = ..eu
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${da
Le 26/01/2011 18:55, Andy Spiegl a écrit :
> On 2011-01-11, 18:17, Victor Duchovni wrote:
>> Postfix recipient validation works by locating valid user addresses
>> in a suitable (address-class dependent) lookup table. Additionally,
>> regardless of the address class, the virtual(5) table can alias
On 2011-01-11, 18:17, Victor Duchovni wrote:
> Postfix recipient validation works by locating valid user addresses
> in a suitable (address-class dependent) lookup table. Additionally,
> regardless of the address class, the virtual(5) table can alias an
> arbitrary recipient to one or more (hopeful
On Thu, Jan 13, 2011 at 02:27:45AM +0100, mouss wrote:
> the idea is
No, the idea is rather different.
> mysql> select substring_index("joe@example", ".", -1);
> +-+
> | substring_index("joe@example", ".", -1) |
> +-
Le 12/01/2011 00:09, Andy Spiegl a écrit :
>> More specifically, "u...@example.com" is a defined email address and
>> you want to accept all "prefix.u...@example.com" variants for valid
>> users and arbitrary prefixes?
> Exactly!
>
>> Well, it is not really an "extension", rather a prefix.
> Oops
On Wed, Jan 12, 2011 at 12:09:40AM +0100, Andy Spiegl wrote:
> > More specifically, "u...@example.com" is a defined email address and
> > you want to accept all "prefix.u...@example.com" variants for valid
> > users and arbitrary prefixes?
>
> Exactly!
>
> > You need a "tcp table", or MySQL virt
> More specifically, "u...@example.com" is a defined email address and
> you want to accept all "prefix.u...@example.com" variants for valid
> users and arbitrary prefixes?
Exactly!
> Well, it is not really an "extension", rather a prefix.
Oops, you are right of course.
> You need a "tcp table",
ot; is a defined email address and
you want to accept all "prefix.u...@example.com" variants for valid
users and arbitrary prefixes?
> If I understand the manual right the recipient_delimiter variable is
> not good for this. Can you guys give me a hint on how this can be
> don
Hi,
I'd like to configure postfix to accept recipient addresses like
foo.u...@domain
bar.u...@domain
baz.u...@domain
without defining an alias for each address.
If I understand the manual right the recipient_delimiter variable is
not good for this. Can you guys give me a hint on how thi
On Mon, Aug 30, 2010 at 08:01:10PM -0700, Constance Mallon wrote:
>
> I have a question regarding recipient delimiters. I need to set the
> recipient delimiter for my mailing lists (mailman) with "-" but I also
> need to set the recipient_delimiter to "+" for my
I have a question regarding recipient delimiters. I need to set the recipient
delimiter for my mailing lists (mailman) with "-" but I also need to set the
recipient_delimiter to "+" for my calendar server.
How can I set the recipient_delimiter to include both values?
ails from
> > > > SASL authenticated users. It seems that unlike access(5) maps, the
> > > > lookup for smtpd_sender_login_maps for addresses which contain
> > > > $recipient_delimiter is not tried at all without the extension:
> > >
> > > This
rs. It seems that unlike access(5) maps, the
> > > lookup for smtpd_sender_login_maps for addresses which contain
> > > $recipient_delimiter is not tried at all without the extension:
> >
> > This is false. Exactly the same code handles access table lookups as
>
maps for addresses which contain
> > $recipient_delimiter is not tried at all without the extension:
>
> This is false. Exactly the same code handles access table lookups as
^
> sender login lookups, only the int
On Sun, Jul 18, 2010 at 12:14:17PM +0200, Stefan Foerster wrote:
> Given: A dedicated Postfix instance, configured to accept mails from
> SASL authenticated users. It seems that unlike access(5) maps, the
> lookup for smtpd_sender_login_maps for addresses which contain
> $recipient_
* Stefan Foerster :
> # postmulti -i postfix-sasl -x postconf recipient_delimiter
> smtpd_sender_login_maps
> recipient_delimiter = +
> smtpd_sender_login_maps = proxy:pgsql:${maps_dir}/sasl-maps.pgsql
Damn. While editing, I accidentally deleted the ".restricted" at th
Given: A dedicated Postfix instance, configured to accept mails from
SASL authenticated users. It seems that unlike access(5) maps, the
lookup for smtpd_sender_login_maps for addresses which contain
$recipient_delimiter is not tried at all without the extension:
# postmulti -i postfix-sasl -x
* Noel Jones [28/05/2010 09:21] :
>
> Yes, man 5 access, look for the "email address extension" section.
Brillant. Thanks, Noel.
Emmanuel
relay is
check_recipient_access hash:/etc/postfix/users where /etc/postfix/users
contains :
OK
OK
OK
OK
OK
REJECT
This ensures that mail for inexistant users is blocked as soon as possible
and it's worked well for months.
I now want to activate recipient_delimiter bu I'v
stfix/users where /etc/postfix/users
contains :
OK
OK
OK
OK
OK
REJECT
This ensures that mail for inexistant users is blocked as soon as possible
and it's worked well for months.
I now want to activate recipient_delimiter bu I've realized that it's
incompatible with the recip
ath.ucla.edu
mynetworks = 128.97.4.0/24, 128.97.19.0/24, 128.97.70.0/24, 128.97.12.0/24
127.0.0.0/8
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix/README_FILES
recipient_delimiter = +
relay_clientcerts = has
On 17-Apr-2010, at 22:09, Jim Carter wrote:
>
> I have recipient_delimiter = + in main.cf, but postconf -d reports that
> the variable is empty.
postconf -d will *always* report that as empty.
Have you looked at the man page for postconf -d to see what it does? (H
INT: It's not
On Sat, 17 Apr 2010, Jim Carter wrote:
> I have recipient_delimiter = + in main.cf, but postconf -d reports that
> the variable is empty. What could be suppressing setting it?
-d is for DEFAULT. The -n flag is what you use to display non-default
parameter settings. See the postconf(
Our mailing list situaton is a little different from what normal list
software handles, so I'm trying to roll my own. I want to use address
extensions to identify the list. /etc/postfix/main.cf includes only
one instance of:
recipient_delimiter = +
For testing, the user sends to , a
Ralf Hildebrandt schrieb:
check_recipient_access hash:/etc/postfix/recipient_access
user.s...@example.com REJECT
Thanx, that is more easy to use :)
1 - 100 of 149 matches
Mail list logo
