On 04 Dec 2019, at 09:52, Viktor Dukhovni wrote:
>$ config_directory=$(postconf config_directory)
>$ maps="proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf
> hash:$config_directory/virtual"
>$ postmap -q ama...@myvirtualdomain.tld $maps
Aha! I was only checking virtual
On Wed, Dec 04, 2019 at 08:10:20AM -0700, @lbutlr wrote:
> On 03 Dec 2019, at 15:27, @lbutlr wrote:
> > I have several domains, all of which have addresses with address delimiters
> > in use. One domain is rejecting all addresses with address extensions in
> > the lmtpd
On 03 Dec 2019, at 15:27, @lbutlr wrote:
> I have several domains, all of which have addresses with address delimiters
> in use. One domain is rejecting all addresses with address extensions in the
> lmtpd stage (after passing in smtpd).
# postconf -n
alias_database = hash:$config_
I have several domains, all of which have addresses with address delimiters in
use. One domain is rejecting all addresses with address extensions in the lmtpd
stage (after passing in smtpd).
All the domains are in a single sql database and I do not see any differences
in the sql definition
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 supports only
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 recipient_delimiter can be multiple characters. :) (I do
Yes and no.
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.
.
recipient_delimiter (default: empty)
The set of characters that can separate user names and
address extensions (user+foo). See canonical(5),
local(8), relocated(5) and virtual(5) for the effects
this has on aliases, canonical, virtual, and relocated
in
fact multiple lookups are made, and the recipient delimiter is
inferred from the shortest match (try postfix - ..., then
postfix-users + ...).
If we do add support for destination specific address extensions
on output, what should be done with the wrong extension on input?
Hypothetical
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.
Thanks. A very minor complaint is that
of an email address decides to use address extensions,
then she should choose a username that doesn't contain any of the
common user/extension delimiters.
Wietse
/dev/rob0:
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.
Thanks. A very
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 trending
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 use now,
Wietse Venema:
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
the delimiter in the email address
was; Postfix does not use that when it searches forward_path.
Wietse
recipient_delimiters (default: $recipient_delimiter)
The set of characters that can separate user names and
address extensions (user+foo). See canonical(5
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 characters
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 character. Please
also note
/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. Please
also note that the word
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
On Thu, June 28, 2012 15:21, Noel Jones wrote:
On 6/28/2012 10:54 AM, James B. Byrne wrote:
And in virtual_aliases_maps those entries in virtual_mailbox_maps
need be mapped to actual delivery points that cyrus-imapd
recognizes:
Actual user-mailbox mapping is done is cyrus. Postfix neither
Thank you for your assistance. I am not concerned that the advice I
receive is wrong. My limited experience with Postfix simply makes it
difficult for me to grasp the entire meaning and implications of what
I am told.
Perhaps this would be clearer to me if you would be so kind as to give
me the
On Thu, June 28, 2012 06:36, James B. Byrne wrote:
Perhaps this would be clearer to me if you would be so kind as to give
me the canonical use cases for virtual_aliases and for virtual_domains
This should read virtual_mailbox_domains
insofar as Postfix considers them. Why is the latter
On Thu, June 28, 2012 11:05, k...@rice.edu wrote:
One item to keep in mind is that if you use the local(8) for mailbox
delivery, you cannot use the Cyrus single-instance store functionality
where a message sent to multiple recipients is only stored once on
the filesystem. The local agent
On 6/28/2012 5:36 AM, James B. Byrne wrote:
Thank you for your assistance. I am not concerned that the advice I
receive is wrong. My limited experience with Postfix simply makes it
difficult for me to grasp the entire meaning and implications of what
I am told.
Perhaps this would be
On 6/28/2012 9:14 AM, James B. Byrne wrote:
On Thu, June 28, 2012 11:05, k...@rice.edu wrote:
One item to keep in mind is that if you use the local(8) for mailbox
delivery, you cannot use the Cyrus single-instance store functionality
where a message sent to multiple recipients is only
On Thu, June 28, 2012 13:41, Noel Jones wrote:
cyrus_destination_recipient_limit=1 means deliver a maximum of one
recipient to each cyrus transport defined in master.cf, which
pipes to the cyrus deliver program; there may be multiple
processes running in parallel.
Apparently some versions
On Thu, June 28, 2012 13:11, Noel Jones wrote:
virtual_mailbox_domains / virtual_mailbox_maps is for the typical
hosted domain with recipients that may or may not be actual unix
users and the possibility of many separate domains coexisting on the
same server. Delivery to the mailstore may
On 6/28/2012 10:18 AM, James B. Byrne wrote:
On Thu, June 28, 2012 13:41, Noel Jones wrote:
cyrus_destination_recipient_limit=1 means deliver a maximum of one
recipient to each cyrus transport defined in master.cf, which
pipes to the cyrus deliver program; there may be multiple
processes
On Thu, June 28, 2012 14:48, Noel Jones wrote:
One example configuration does not exclude other possible
configurations.
The difficulty I face is excluding those which either do not work or
are not particularly robust. I am not conversant with the inner
working of either Postfix or
On 6/28/2012 10:54 AM, James B. Byrne wrote:
Given that on the final delivery host we treat ALL of our domains,
real and virtual, as virtual for the purposes of email;
And the final delivery host is NOT listed as MX for any domain;
And we are using cyrus-imap;
And we take the
First, I thank everyone who has been kind enough to provide me with
guidance. I appreciate it very much.
Second, I wish to recap my present situation so that any remaining
misunderstandings on my part are exposed to your observation and
comments.
The background is this. We are moving from a
On 6/27/2012 8:47 AM, James B. Byrne wrote:
The background is this. We are moving from a Sendmail/Cyrus-imap
based system of many years to a Postfix/Cyrus-imap based email system.
During the transitions the existing Sendmail/Cyrus-imap service
naturally remains active.
You describe a
On Wed, June 27, 2012 14:28, Noel Jones wrote:
On 6/27/2012 8:47 AM, James B. Byrne wrote:
The background is this. We are moving from a Sendmail/Cyrus-imap
based system of many years to a Postfix/Cyrus-imap based email
system.
During the transitions the existing Sendmail/Cyrus-imap
On 6/27/2012 11:31 AM, James B. Byrne wrote:
On Wed, June 27, 2012 14:28, Noel Jones wrote:
On 6/27/2012 8:47 AM, James B. Byrne wrote:
The background is this. We are moving from a Sendmail/Cyrus-imap
based system of many years to a Postfix/Cyrus-imap based email
system.
During the
I now have this working properly for a test account. It seems to me
now that many of my difficulties stem from trying to map Sendmail
techniques to Postfix.
I am now considering the relationship between /etc/postfix/virtual and
/etc/postfix/relay_domains. To deliver email to a local mailbox
On 6/26/2012 8:35 AM, James B. Byrne wrote:
I now have this working properly for a test account. It seems to me
now that many of my difficulties stem from trying to map Sendmail
techniques to Postfix.
I am now considering the relationship between /etc/postfix/virtual and
On Mon, June 25, 2012 18:47, Bill Cole wrote:
On 25 Jun 2012, at 14:03, James B. Byrne wrote:
[...]
The virtual_aliases map contains this:
@example.com someuser
So that any address in example.com is entirely replaced with the local
address someuser, no
On 6/26/2012 12:48 PM, James B. Byrne wrote:
My point of confusion at the moment is the relationship between
/etc/postfix/virtual and /etc/aliases (or in our case
/etc/postfix/aliases.main).
http://www.postfix.org/ADDRESS_REWRITING_README.html
virtual_alias_maps apply to *all* addresses,
and user.example.delivery have the cyrus-imapd acl
anyone:p set as is required for extended delivery.
/etc/postfix/main.cf has this setting:
# ADDRESS EXTENSIONS (e.g., user+foo)
#
# The recipient_delimiter parameter specifies the separator between
# user names and address extensions (user+foo). See canonical(5
On 25 Jun 2012, at 14:03, James B. Byrne wrote:
[...]
The virtual_aliases map contains this:
@example.com someuser
So that any address in example.com is entirely replaced with the local
address someuser, no matter what the local part of the original address
Hello list,
I am finding that
postmap -q address+withextens...@domain.com
pgsql:/etc/postfix/virtual_mailbox_maps
does not return a result, while the address without the extension
works fine. Is this expected behaviour?
--
martin | http://madduck.net/ | http://two.sentenc.es/
the problem
martin f krafft:
Hello list,
I am finding that
postmap -q address+withextens...@domain.com
pgsql:/etc/postfix/virtual_mailbox_maps
does not return a result, while the address without the extension
works fine. Is this expected behaviour?
YES.
Wietse
also sprach Wietse Venema wie...@porcupine.org [2010.08.28.2330 +0200]:
does not return a result, while the address without the extension
works fine. Is this expected behaviour?
YES.
Thank you.
--
martin | http://madduck.net/ | http://two.sentenc.es/
common sense is the collection
of
martin f krafft:
also sprach Wietse Venema wie...@porcupine.org [2010.08.28.2330 +0200]:
does not return a result, while the address without the extension
works fine. Is this expected behaviour?
YES.
Thank you.
You're welcome.
By now you will be aware that postmap does not know
Frank Cusack:
I can't get the relay_recipient_maps lookup to ignore the address
extension part of a recipient email address. It's very difficult to
use address extensions together with relay_recipient_maps this way.
Am I missing some configuration setting? I've been searching
of a recipient email address. It's very difficult to
use address extensions together with relay_recipient_maps this way.
Am I missing some configuration setting? I've been searching for it
for about an hour.
-frank
Daniel L. Miller wrote:
Noel Jones wrote:
either way, use smtpd_*_restrictions to restrict access to the
recipient.
What kind of allow restrictions would make sense as I am looking to
receive from a domain I do not control (e.g. Intuit)? Would
check_sender_access against the domain be
. However, I'm now wondering if I
can accomplish the same thing by using address extensions instead
of a different server name. So I'd be sending emails to
1234567890+...@mydomain.com, and Postfix would then identify a
fax is to be sent by the extension, translate that to
1234567
Daniel L. Miller wrote:
Daniel L. Miller wrote:
Noel Jones wrote:
either way, use smtpd_*_restrictions to restrict access to the
recipient.
What kind of allow restrictions would make sense as I am looking to
receive from a domain I do not control (e.g. Intuit)? Would
check_sender_access
submissions from Intuit. However, I'm now wondering if I
can accomplish the same thing by using address extensions instead
of a different server name. So I'd be sending emails to
1234567890+...@mydomain.com, and Postfix would then identify a
fax is to be sent by the extension, translate
I'm trying to implement a mail-to-fax gateway, and I thought address
extensions might help me. If I'm approaching this wrong please correct me.
I've already proven to myself that I can define a fax service in
master.cf, add a fax transport mapping, and it works great. However,
this uses
address extensions instead of a different server
name. So I'd be sending emails to 1234567890+...@mydomain.com, and
Postfix would then identify a fax is to be sent by the extension,
translate that to 1234567...@fax.myinternaldomain.com, and process
accordingly. I would still have to protect
can accomplish
the same thing by using address extensions instead of a different server
name. So I'd be sending emails to 1234567890+...@mydomain.com, and
Postfix would then identify a fax is to be sent by the extension,
translate that to 1234567...@fax.myinternaldomain.com
wondering if I can accomplish
the same thing by using address extensions instead of a different server
name. So I'd be sending emails to 1234567890+...@mydomain.com, and
Postfix would then identify a fax is to be sent by the extension,
translate that to 1234567...@fax.myinternaldomain.com
The mailbox transport I use is a pipe to an MDA that treats the username
case-sensitively, so I have given the u flag in the transport, but
I also have
recipient_delimiter = +
and the address extensions are being downcased as well.
Does postfix offer a better solution
56 matches
Mail list logo
