check_recipient_access after rewrite happens

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

check_recipient_access after rewrite happens

Andreas Thienemann
Hi,

During migration of an inherited mail system I have the situation that I
would like to reject certain recipient address _after_ they have been
rewritten through the virtual_alias_maps.

The old system had a spam sink where users could redirect certain local
parts. e.g. a user has a catchall account on his domain example.com but
has burned [hidden email] and it is full of spam. The user is able to
configure a redirect from [hidden email] to "spam".
Before the "spam" address was sinkholed via an alias entry that would run
a bit of analytics on the incoming spam and otherwise discard the input.

On the new system I would like to skip all as it was kind of error prone
and just outright reject mail.

My initial plan was to just have a check_recipient_access
hash:/etc/postfix/access_rcpt line added to the
smtpd_recipient_restrictions config item.

In the logs, I can see that the access table is being consulted but
unfortunately it is consulted for the raw RCPT TO header as received from
the client. This is unfortunately before rewriting happens and my
access_rcpt entry matching on spam@{{ $mydestination }} is not queried at
all according to the logs.

Is there a way to configure postfix to check after rewriting of addresses?

cheers,
  Andreas

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Wietse Venema
Andreas Thienemann:
> Hi,
>
> During migration of an inherited mail system I have the situation that I
> would like to reject certain recipient address _after_ they have been
> rewritten through the virtual_alias_maps.

The SMTP daemon acces rules currently do not have access to that
information. In the things to do, this has high cost and therefore
low priority.

If you have a virtual alias that rewrites an address to the spam
sink, specify that address in the SMTP daemon acces rules instead.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Andreas Thienemann
In reply to this post by Andreas Thienemann
Hi,

On Tue, 19 Sep 2017, Wietse Venema wrote:

> >  During migration of an inherited mail system I have the situation that I
> >  would like to reject certain recipient address _after_ they have been
> >  rewritten through the virtual_alias_maps.
>
>  The SMTP daemon acces rules currently do not have access to that
>  information. In the things to do, this has high cost and therefore
>  low priority.

I see. Bummer. I am pretty sure it would make life easier though...

>  If you have a virtual alias that rewrites an address to the spam
>  sink, specify that address in the SMTP daemon acces rules instead.

You mean something like "SELECT '554 Spamtrap' FROM routes WHERE dest IN
('spam', 'spam-mails');" in the sql lookup table and then use that as a
check_recipient_access table?

That would work. A bit of a hack though and I think it would only work for
virtual aliases with one level of redirection but not for something like
[hidden email] -> [hidden email] -> spam-mails.

But I should get most of the problematic entries with that. Thanks for the
suggestion.

cheers,
   Andreas

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Wietse Venema
Andreas Thienemann:

> Hi,
>
> On Tue, 19 Sep 2017, Wietse Venema wrote:
>
> > >  During migration of an inherited mail system I have the situation that I
> > >  would like to reject certain recipient address _after_ they have been
> > >  rewritten through the virtual_alias_maps.
> >
> >  The SMTP daemon acces rules currently do not have access to that
> >  information. In the things to do, this has high cost and therefore
> >  low priority.
>
> I see. Bummer. I am pretty sure it would make life easier though...
>
> >  If you have a virtual alias that rewrites an address to the spam
> >  sink, specify that address in the SMTP daemon acces rules instead.
>
[,,,]
> That would work. A bit of a hack though and I think it would only work for
> virtual aliases with one level of redirection but not for something like
> [hidden email] -> [hidden email] -> spam-mails.

Yes, you'd need one SMTP daemon acces rule for each 'top-level' alias.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Viktor Dukhovni
In reply to this post by Andreas Thienemann

> On Sep 19, 2017, at 8:39 PM, Andreas Thienemann <[hidden email]> wrote:
>
> That would work. A bit of a hack though and I think it would only work for virtual aliases with one level of redirection but not for something like [hidden email] -> [hidden email] -> spam-mails.

Some SQL implementations support recursive CTEs, or you can periodically
construct a table that holds the recursive closure of such aliases.

Do be careful though to only apply the rule to 1-to-1 aliases, and not
1 to many groups, just in case a group contains a member that maps to
such an address (that's likely a misconfiguration, but could happen).

In some schemas groups that expand to multiple addresses are stored
differently than users that might have an email redirect.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Andreas Thienemann
In reply to this post by Andreas Thienemann
Hi,

On Wed, 20 Sep 2017, Wietse Venema wrote:

> > >   If you have a virtual alias that rewrites an address to the spam
> > >   sink, specify that address in the SMTP daemon acces rules instead.
> >
>  [,,,]
> >  That would work. A bit of a hack though and I think it would only work for
> >  virtual aliases with one level of redirection but not for something like
> >  [hidden email] -> [hidden email] -> spam-mails.
>
>  Yes, you'd need one SMTP daemon acces rule for each 'top-level' alias.

Thanks for clarifying that was what you meant.

I think I'll skip putting one in for each top-level alias and only support
direct rewrites to the target address. I'll have something like 99.9%
coverage and for the guesstimated 5 accounts affected the error message
will be a bit inaccurate as the recipient validation is getting an error
about spam-mails not being deliverable through lmtp...

I can live with that.

cheers,
   Andreas

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_access after rewrite happens

Wietse Venema
Andreas Thienemann:

> Hi,
>
> On Wed, 20 Sep 2017, Wietse Venema wrote:
>
> > > >   If you have a virtual alias that rewrites an address to the spam
> > > >   sink, specify that address in the SMTP daemon acces rules instead.
> > >
> >  [,,,]
> > >  That would work. A bit of a hack though and I think it would only work for
> > >  virtual aliases with one level of redirection but not for something like
> > >  [hidden email] -> [hidden email] -> spam-mails.
> >
> >  Yes, you'd need one SMTP daemon acces rule for each 'top-level' alias.
>
> Thanks for clarifying that was what you meant.
>
> I think I'll skip putting one in for each top-level alias and only support
> direct rewrites to the target address. I'll have something like 99.9%
> coverage and for the guesstimated 5 accounts affected the error message
> will be a bit inaccurate as the recipient validation is getting an error
> about spam-mails not being deliverable through lmtp...
>
> I can live with that.

Please reconsider. You should reject mail at RCPT TO time,
not after accepting the message into the queue.

If you accept email first, and then return it as undeliverable.
then you will be harassing lots of innocent people about email that
they did not send, and your system may get blacklisted as being a
backscatter source.

        Wietse