--On Tuesday, October 02, 2012 8:11 PM + Viktor Dukhovni
wrote:
On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:
Alas, it makes no sense to me, and I am the person who designed
this mail system.
In particular I fail to understand what this is meant to achieve:
1) list
On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:
> > So, does that look more correct to you as the way to correctly handle this?
>
> Alas, it makes no sense to me, and I am the person who designed
> this mail system.
>
> In particular I fail to understand what this is meant to ac
Quanah Gibson-Mount:
> I changed the value for virtual_transport to be:
>
> error: 5.1.1 Mailbox unavailable
>
> And now I see:
>
> Oct 2 11:54:21 zre-ldap002 postfix/error[331]: 897561E37C6:
> to=, relay=none, delay=0.06,
> delays=0.03/0/0/0.02, dsn=5.1.1, status=bounced (Mailbox unavail
> a
--On Tuesday, October 02, 2012 3:47 PM + Viktor Dukhovni
wrote:
On Tue, Oct 02, 2012 at 08:21:54AM -0400, Wietse Venema wrote:
Quanah Gibson-Mount:
>
> virtual_transport = error
[...]
I could speculate that your "virtual_transport = error" causes the
nexthop to become the recipient dom
On Tue, Oct 02, 2012 at 08:21:54AM -0400, Wietse Venema wrote:
> Quanah Gibson-Mount:
> >
> > virtual_transport = error
>
> [...]
>
> I could speculate that your "virtual_transport = error" causes the
> nexthop to become the recipient domain (zre-ldap002.eng.vmware.com)
> which then is reported
Quanah Gibson-Mount:
> mydestination = localhost
> transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
> virtual_alias_domains = proxy:ldap:/opt/zimbra/conf/ldap-vad.cf
> virtual_alias_expansion_limit = 1
> virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
> virtual_mailbo
On Mon, Oct 01, 2012 at 04:51:15PM -0700, Quanah Gibson-Mount wrote:
> >>We do use LDAP for our transport map for delivery:
> >
> >What is the error if it is not "User unknown in virtual alias table"?
>
> Hi Wieste,
>
> I'm not sure where the error is you are expecting me to find? This
> is the
--On Monday, October 01, 2012 8:04 PM -0400 Wietse Venema
wrote:
Quanah Gibson-Mount:
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
: zre-ldap002.eng.vmware.com
I have two questions. Pl
Quanah Gibson-Mount:
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>The mail system
>
> : zre-ldap002.eng.vmware.com
I have two questions. Please answer both, if may save us 50%
of the time.
What is "
--On Monday, October 01, 2012 7:32 PM -0400 Wietse Venema
wrote:
Quanah Gibson-Mount:
>> There are tons of ways that mail can resolve to the error mailer;
>> some may even be specified in access maps or transport maps.
>
> If the error is "User unknown in virtual alias table", then the fix
>
Quanah Gibson-Mount:
> >> There are tons of ways that mail can resolve to the error mailer;
> >> some may even be specified in access maps or transport maps.
> >
> > If the error is "User unknown in virtual alias table", then the fix
> > is in trivial-rewrite/resolve.c:
> >
> > < vstring_
On Mon, Oct 01, 2012 at 03:31:12PM -0700, Quanah Gibson-Mount wrote:
> I read the page on transport maps, but I don't see a bit in there
> for setting the recipient unknown dsn code.
The nexthop syntax is naturally transport dependent, the specification
for the error(8) transport is in the error
--On Monday, October 01, 2012 5:28 PM -0400 Wietse Venema
wrote:
Wietse Venema:
Quanah Gibson-Mount:
> I got a complaint from a client that postfix is returning a "5.0.0"
> DSN when emails are sent to an unknown user. I believe this is to
> prevent backscatter. In any case, it appears thi
Wietse Venema:
> Quanah Gibson-Mount:
> > I got a complaint from a client that postfix is returning a "5.0.0" DSN
> > when emails are sent to an unknown user. I believe this is to prevent
> > backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
> > into the error daemon?
Quanah Gibson-Mount:
> I got a complaint from a client that postfix is returning a "5.0.0" DSN
> when emails are sent to an unknown user. I believe this is to prevent
> backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
> into the error daemon?
>
> >From my logs I see:
I got a complaint from a client that postfix is returning a "5.0.0" DSN
when emails are sent to an unknown user. I believe this is to prevent
backscatter. In any case, it appears this 5.0.0 DSN response is hard coded
into the error daemon?
From my logs I see:
Oct 1 13:11:07 zre-ldap002 p
16 matches
Mail list logo
