Dirk St?cker:
> Hello,
>
> I'm operating a bug tracker which sends out emails to participants
> notifying of ticket changes. For new submitters it often happened, that
> they simply did reply by mail which wont work with this instance.
>
> Now I changed our setup a bit
>
> In postfix main.cf:
> smtpd_recipient_restrictions = ...check_recipient_access
> hash:/etc/postfix/recipient_access...
>
> and
> recipient_access:
> t...@mail.tld reject This trac does not have an e-mail input functionality.
>
> This works like a charm, but then today something new did pop up. Sender
> verify. It seems there are mail servers outside which connect back to the
> original server and check for errors:
>
> 550-Verification failed for <t...@email.tld> 550-Previous
> (cached) callout verification failure 550 Sender verify failed (in reply
> to
> RCPT TO command)
>
> This prevents to notify them completely, as their servers wont accept any
> mail from the ticket system. Turning off that feature I'd need to manually
> inform mail senders again which I want to prevent.
>
> Is there any solution to satisfy the "no-reply" mail address feature and
> these sender verifiers. They don't actually send a mail, so maybe my
> reject can come a bit later in the mail receiving process?
Whitelist the address up-stream:
....
reject_unauth_destination
check_recipient_access inline:{t...@mail.tld=permit}
reject_unverified_recipient
....
or the equivalent idiom for a non-Postfix system that makes the callout.
Wietse
