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?
> >
> > >From my logs I see:
> >
> > Oct 1 13:11:07 zre-ldap002 postfix/smtp[8257]: 000501E37BC:
> > to=<badu...@zre-ldap002.eng.vmware.com>, relay=127.0.0.1[127.0.0.1]:10026,
> > delay=0.22, delays=0.03/0/0/0.19, dsn=2.0.0, status=sent (250 2.0.0 from
> > MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 2D0711E37BE)
> > Oct 1 13:11:07 zre-ldap002 postfix/qmgr[23910]: 000501E37BC: removed
> > Oct 1 13:11:07 zre-ldap002 postfix/error[8324]: 2D0711E37BE:
> > to=<badu...@zre-ldap002.eng.vmware.com>, relay=none, delay=0.06,
> > delays=0.03/0/0/0.02, dsn=5.0.0, status=bounced (zre-ldap002.eng.vmware.com)
> >
> > And in the source I see:
> >
> > if (strcmp(service, MAIL_SERVICE_ERROR) == 0)
> > status = deliver_message(request, "5.0.0", bounce_append);
>
> The error daemon uses "5.0.0" as the **default** status code, when
> whoever decided to route mail to the error daemon did not provide
> a valid status code.
>
> 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_sprintf(nexthop, "User unknown%s",
---
> vstring_sprintf(nexthop, "5.1.1 User unknown%s",
It the error is different, then I'll have to wait for more specific
information.
Wietse
