On Mon May 11 2009 14:45:14 Eric Cunningham wrote:
> This may be of use in my situation. Can you point me to the docs
> that explain how to configure wildcard subdomains?
postconf.5.html#parent_domain_matches_subdomains ... one way
pcre_table.5.html ... another way
regexp_table.5.html ... another
Noel Jones wrote:
Eric Cunningham wrote:
I want e...@sanguine.whoi.edu to continue delivery to my imap
account. In fact, that happened perfectly in my previous postfix
configuration.
... it worked previously due to a bug in permit_mx_backup. That bug has
been corrected.
Ahh...finally, s
Eric Cunningham wrote:
I want e...@sanguine.whoi.edu to continue
delivery to my imap account. In fact, that happened perfectly in my
previous postfix configuration.
... it worked previously due to a bug in permit_mx_backup.
That bug has been corrected.
Since upgrading postfix, in order f
Eric Cunningham:
> that to continue working, I'm now hearing that I must specifically list
> sanguine.whoi.edu "somewhere" in my postfix configs. That's not
> unreasonable, but let's now extend this example to another 250 hosts
> that are in a similar situation. I must now specifically find, l
Noel Jones wrote:
Apparently, sanguine.whoi.edu not listed in any of the postfix address classes.
Which address class do you expect this to be? Then you'll know where the
domain must be listed.
This is one document you need to understand:
http://www.postfix.org/ADDRESS_CLASS_README.html
On Mon May 11 2009 12:08:02 Magnus Bäck wrote:
> On Monday, May 11, 2009 at 18:59 CEST,
> /dev/rob0 wrote:
>
> [...]
>
> > BTW, I always use complete paths for lookups. I think "ldap:vldap"
> > defaults to "ldap:$config_directory/vldap", but it never hurts to
> > be specific, so you know what
Eric Cunningham wrote:
May 11 12:24:19 obtest postfix/postfix-script[4849]: warning:
/var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
Fix the above error. Probably not directly related to your
problem, but might cause unexpected behavior. The fix is
probably just:
# cp /et
...
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap
These are all your address class definitions. We can't see into your
virtual_alias_maps to know what domains might be listed there. You can
show us "postmap -q sanguine.whoi.edu hash:/et
On Monday, May 11, 2009 at 18:59 CEST,
/dev/rob0 wrote:
[...]
> BTW, I always use complete paths for lookups. I think "ldap:vldap"
> defaults to "ldap:$config_directory/vldap", but it never hurts to
> be specific, so you know what you're getting.
ldap:vldap is the legacy configuration meth
On Mon May 11 2009 11:33:37 Eric Cunningham wrote:
> I guess I'm still missing something so here's my 'postfix -n' output
> and logfile showing the rejection.
> >>> for postfix to accept mail for a domain (from anywhere), the
> >>> domain needs to be found in one (and only one of):
> >>> - mydesti
I guess I'm still missing something so here's my 'postfix -n' output and
logfile showing the rejection.
-Eric
for postfix to accept mail for a domain (from anywhere), the domain
needs to be found in one (and only one of):
- mydestination (this is for mail delivered to a unix a
Eric Cunningham a écrit :
> Thanks mouss. I removed $mynetworks from relay_domains and added the
> domains found in the transport map to relay_domains (while also keeping
> them in the transport map). Relaying to those specific domains now works.
>
> However, MX'd machines still suffer "relay a
Thanks mouss. I removed $mynetworks from relay_domains and added the
domains found in the transport map to relay_domains (while also keeping
them in the transport map). Relaying to those specific domains now works.
However, MX'd machines still suffer "relay access denied." I introduced
"re
Eric Cunningham a écrit :
> Thanks Victor. Ok, so I:
>
> - removed .$mydomain from $mydestination
> - have set relay_domains = $mydestination, $mynetworks
do not do that. mydestination is for domains that should be delivered
locally. mynetworks have nothing to do with reception domains.
Thanks Victor. Ok, so I:
- removed .$mydomain from $mydestination
- have set relay_domains = $mydestination, $mynetworks
- have set parent_domain_matches_subdomains to it's default
- have added permit_mx_backup to smtpd_recipient_restrictions
- set permit_
On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:
> I think I've found a/the fix for re-enabling the original behavior of my
> transport maps and MX relaying. I added .$mydomain to mydestination in
> main.cf. This is in addition to $mydomain which was already in
> mydestination
I think I've found a/the fix for re-enabling the original behavior of my
transport maps and MX relaying. I added .$mydomain to mydestination in
main.cf. This is in addition to $mydomain which was already in
mydestination.
$mydomain vs. .$mydomain is subtle but apparently important.
Eric Cunningham:
> > transport_maps simply routes accepted messages by overriding DNS.
>
> That's what I want to continue to do, as had occurred happily before the
> postfix upgrade.
>
> > To accept mail, the envelope recipient *must* be in mydestination,
> > relay_domains, virtual_alias_domains
transport_maps simply routes accepted messages by overriding DNS.
That's what I want to continue to do, as had occurred happily before the
postfix upgrade.
To accept mail, the envelope recipient *must* be in mydestination,
relay_domains, virtual_alias_domains or virtual_mailbox_domains.
All
Eric Cunningham:
[ Charset ISO-8859-1 unsupported, converting... ]
> > Why don't you simply restore the old working main.cf and master.cf
> > files, and then execute as root:
> >
> > # postfix upgrade-configuration
> >
> > This is easier that trying to figure out how to rebuild the old
> > co
Why don't you simply restore the old working main.cf and master.cf
files, and then execute as root:
# postfix upgrade-configuration
This is easier that trying to figure out how to rebuild the old
configuration from scratch.
PS If the recipient domains are not local, then they must be listed
Eric Cunningham:
> I just upgraded to postfix 2.5.5 from 2.3. Now, it seems my previously
> working transport maps are ignored as are hosts that are MX'ed to the
> machine running postfix. In both cases, email are rejected with "Relay
> access denied."
Why don't you simply restore the old wor
Eric Cunningham wrote:
> I just upgraded to postfix 2.5.5 from 2.3. Now, it seems my
> previously working transport maps are ignored as are hosts that are
> MX'ed to the machine running postfix. In both cases, email are
> rejected with "Relay access denied."
> Sorry, thank you for the clarificati
Sorry, thank you for the clarification, Brian. 'postconf -n' output is
now attached. I've already run 'postmap transport' and 'postfix reload'
but that didn't help.
I did find a quasi-workaround to this by adding the subdomains from
transport to relay_domains but that will be clumsy at best
Eric Cunningham wrote:
> I just upgraded to postfix 2.5.5 from 2.3. Now, it seems my
> previously working transport maps are ignored as are hosts that are
> MX'ed to the machine running postfix. In both cases, email are
> rejected with "Relay access denied."
>
> I note in the attached 'postconf -
I just upgraded to postfix 2.5.5 from 2.3. Now, it seems my previously
working transport maps are ignored as are hosts that are MX'ed to the
machine running postfix. In both cases, email are rejected with "Relay
access denied."
I note in the attached 'postconf -d' output that transport_maps
26 matches
Mail list logo
