[pfx] smtpd filter orig_client

2024-03-18 Thread Reg Inaldo via Postfix-users


Hi

I am seeing an issue with relaying and am looking for a way to filter on 
a specific smtp line but can't find a way to make it work:


In the transaction (eg):  mta-k postfix/smtpd[23771]: 97F808837: 
client=localhost[127.0.0.1], orig_client=localhost[127.0.0.1]


I want to reject anything on the "orig_client" basis where: 
*orig_client**=localhost*[127.0.0.1]


All of the standard submissions to the MTAs include the originating 
server, eg:  client=localhost[127.0.0.1], 
orig_client=m236-67.mailgun.net[159.135.236.67]


The fact that they are all coming via 'client=localhost' makes it 
difficult to just use that term.


Any suggestions are welcomed.

Thanks

Reg

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Viktor Dukhovni via Postfix-users
On Mon, Mar 18, 2024 at 12:20:09AM -0700, Glenn Tenney via Postfix-users wrote:

> > transport:
> > u...@domain.nameerror:5.1.1 purported to not exist
> >
> >
> 
> Thank you very much. A question please… the above two “solutions” seem to
> accomplish very similar tasks: to reject user@domain.example issuing an
> error to the sender… but…

Yes, quite similar, though not completely identical.

> It would seem that the 2nd solution using transport_maps is simpler to
> implement,

Only if you don't already have any access(5) checks.  Either way, you
add an entry to a table.

The transport(5) approach makes the recipient *undeliverable* even for
locally submitted mail, and even after alias expansion, but either way
only the *verabatim* recipient address is rejected after SMTP "RCPT TO".

> but there may be a variety of reasons to choose one solution
> over the other.

Mostly a matter of taste, the recipient restrictions are the more common
approach, but the transport(5) mapping to "error" is also fine.

> Is there some relatively straightforward criteria to consider which of
> your two “solutions” is better or more efficient?

Neither is noticeably more "efficient", either way a cheap table lookup.

> It’s clear that there are going to be multiple ways to accomplish the
> same task.

Yes, many ways, and overlap with per-address class valid recipient
tables, ... (local_recipient_maps, virtual_mailbox_maps,
relay_recipient_maps).

Which is why just cargo-cult is difficult to specify without the full
picture of your entire setup, but that's too much work to take in unless
you hire a paid consultant.  In your place, I'd have stuck with Sendmail
on FreeBSD, while you're learning to use Postfix on some toy machines,
reading docs more deeply, ...

Another option is a turnkey solution, such as: https://mailinabox.email

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Viktor Dukhovni via Postfix-users
On Mon, Mar 18, 2024 at 12:50:18AM -0700, Glenn Tenney via Postfix-users wrote:
> On Monday, March 18, 2024, Benny Pedersen via Postfix-users <
>
> > Victor gave a vierd config :)
> >
> > postfix must not return any result on non existsing users, so if this
> > gives no result user is unknown, with in turn gives postfix user not found,
> > to keep things very simple mydestination must only have unix users where @
> > is not auth without realm-domain, when this is in place you  can in
> > virtual_alias_maps map remote mail recipient to system users mailbox, of
> > not all is virtual_domained
> >
> 
> 
> Thanks. I’m hosting several domains: a couple need to accept any user@
> except some that specifically need to be rejected delivering locally; some
> domains are more normal, just accept specific users & deliver to some local
> user (sometimes using procmail to forward some or save some to files); and
> a few domains that will deliver to some-other domain (kinda relay). So only
> the first of these need to return a result (reject) specific users.

Benny is at times too eager to answer more questions than he can give
justice to.  Tread with care.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Glenn Tenney via Postfix-users
On Monday, March 18, 2024, Benny Pedersen via Postfix-users <
postfix-users@postfix.org> wrote:

> catch all is badly advised, it makes recipient validation impososibe,
> don't do it
>
> define maps with what is wanted, not with what is not wanted, catch-all is
> unwanted
>

I know, but a couple of domains create email addresses at any time with no
notice, so I’ve got to “allow all unless a userid has been set to be
rejected” for those domains.

Glenn
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Benny Pedersen via Postfix-users

Glenn Tenney via Postfix-users skrev den 2024-03-18 08:50:


Thanks. I’m hosting several domains: a couple need to accept any
user@ except some that specifically need to be rejected delivering
locally; some domains are more normal, just accept specific users &
deliver to some local user (sometimes using procmail to forward some
or save some to files); and a few domains that will deliver to
some-other domain (kinda relay). So only the first of these need to
return a result (reject) specific users.


catch all is badly advised, it makes recipient validation impososibe, 
don't do it


define maps with what is wanted, not with what is not wanted, catch-all 
is unwanted


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Glenn Tenney via Postfix-users
On Monday, March 18, 2024, Benny Pedersen via Postfix-users <
postfix-users@postfix.org> wrote:

> Glenn Tenney via Postfix-users skrev den 2024-03-18 03:52:
>
> My question in one, hopefully simple sentence, is:
>>
>> In Postfix, how do I configure Postfix such that all email to
>> "user@some.domain" will return an error code (e.g. 550 user unknown)
>> to bounce that email
>>
>
> Victor gave a vierd config :)
>
> postfix must not return any result on non existsing users, so if this
> gives no result user is unknown, with in turn gives postfix user not found,
> to keep things very simple mydestination must only have unix users where @
> is not auth without realm-domain, when this is in place you  can in
> virtual_alias_maps map remote mail recipient to system users mailbox, of
> not all is virtual_domained
>


Thanks. I’m hosting several domains: a couple need to accept any user@
except some that specifically need to be rejected delivering locally; some
domains are more normal, just accept specific users & deliver to some local
user (sometimes using procmail to forward some or save some to files); and
a few domains that will deliver to some-other domain (kinda relay). So only
the first of these need to return a result (reject) specific users.

Glenn
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Benny Pedersen via Postfix-users

Glenn Tenney via Postfix-users skrev den 2024-03-18 03:52:


My question in one, hopefully simple sentence, is:

In Postfix, how do I configure Postfix such that all email to
"user@some.domain" will return an error code (e.g. 550 user unknown)
to bounce that email


Victor gave a vierd config :)

postfix must not return any result on non existsing users, so if this 
gives no result user is unknown, with in turn gives postfix user not 
found, to keep things very simple mydestination must only have unix 
users where @ is not auth without realm-domain, when this is in place 
you  can in virtual_alias_maps map remote mail recipient to system users 
mailbox, of not all is virtual_domained


so in practices use mydestination: localhost

and make virtual all mail for the rest, this fits nicely with dovecot 
then


postmap -q unknown-user hash:/path-to/hash-file

if it gives no result, then this user does not exists

if unknown-user exists, it should give virtual-user-mailbox-storage-user

unsure then show logs if error is there

and lastly show postconf -nf on request, i don't need this yet

i have succes with postfixadmin so no users is in hash files, but in 
sqlite mysql postgresql as you see fit


and i have no use for system users mailboxes



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Help please on converting SENDMAIL VIRTUSERTABLE to postfix

2024-03-18 Thread Glenn Tenney via Postfix-users
On Sunday, March 17, 2024, Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:

> > > - You can reject SMTP recipients via various restriction checks
> > >   that perform access(5) lookups against tables of your choice.
> >
> > How can I do it not based on the network or domain name but a specific
> > u...@domain.name?
>
> By putting that address in an access(5) table with "REJECT " as
> the RHS.  Then add:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_recipient_restrictions =
> permit_mynetworks,
> reject_unauth_destination,
> check_recipient_access ${indexed}rcpt-access
>
> rcpt-access:
> # Postmap after each change
> user1@domain.example REJECT 5.1.1 purported to not exist
> user2@domain.example REJECT 5.7.1 access denied
> ...
>
…

> There is no error(8) table, that's delivery agent.  There's a transport
> table:
>
> main.cf:
> # See "indexed =  ..." above
> transport_maps = ${indexed}transport
>
> transport:
> u...@domain.nameerror:5.1.1 purported to not exist
>
>

Thank you very much. A question please… the above two “solutions” seem to
accomplish very similar tasks: to reject user@domain.example issuing an
error to the sender… but…

It would seem that the 2nd solution using transport_maps is simpler to
implement, but there may be a variety of reasons to choose one solution
over the other. Is there some relatively straightforward criteria to
consider which of your two “solutions” is better or more efficient?

It’s clear that there are going to be multiple ways to accomplish the same
task.

Glenn
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org