[pfx] Re: Restricted Users Emailing Themselves

2023-06-12 Thread Viktor Dukhovni via Postfix-users
On Mon, Jun 12, 2023 at 04:43:42PM -0700, Asai via Postfix-users wrote:

> We have a situation where we want certain company groups to only be able 
> to email others in their group.

Isn't each user a member of "their group?

> I've been managing this through check_sender_access, and
> check_recipient_access with regex lists.

That's rather cumbersome, I think this is better handled with a milter.

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


[pfx] Restricted Users Emailing Themselves

2023-06-12 Thread Asai via Postfix-users

Greetings,

We have a situation where we want certain company groups to only be able 
to email others in their group.


I've been managing this through check_sender_access, and 
check_recipient_access with regex lists.  It's worked for years, but the 
one big problem with it is that it doesn't allow users to email 
themselves without breaking the restrictions.


I've been trying (and failing) to work around this, but I've not 
succeeded yet.


Can anyone offer some advice on the best way to make this work?

Thanks,
Asai

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


[pfx] Re: SPF questions

2023-06-12 Thread Bill Cole via Postfix-users
On 2023-06-12 at 04:19:12 UTC-0400 (Mon, 12 Jun 2023 20:19:12 +1200)
Peter via Postfix-users 
is rumored to have said:

> Technically it's an invalid MX record because MX records must point to a 
> hostname, not an IP address.
>
> They are probably trying (but failing) to implement a null MX record:
>
> https://www.rfc-editor.org/rfc/rfc7505

Also, it may be an artifact of discussions ~2 decades ago about how best to 
express the mail-nonexistence of a domain. I am certain I saw it proposed at 
least twice as a way to make misuse of such a domain noisy and painful.

>
>
> Peter
>
>
> On 12/06/23 19:50, wesley--- via Postfix-users wrote:
>>>
>>> Note there is also RFC 7505 "Null MX" where you simply add "IN MX 0 ." to
>>> any DNS name you wish not to send or accept e-mail. (this is designed to
>>> work around implicie MX records when A record is present).
>>>

>>
>> I saw some domains have MX pointing to 127.0.0.1. what does this mean?
>>
>> Thanks.
>> ___
>> Postfix-users mailing list -- postfix-users@postfix.org
>> To unsubscribe send an email to postfix-users-le...@postfix.org
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: How to stop delivery looping

2023-06-12 Thread Viktor Dukhovni via Postfix-users
On Mon, Jun 12, 2023 at 08:47:10AM +, wesley--- via Postfix-users wrote:

> may I know that, what's the mechanism for postfix to stop mail
> delivery looping?
> 
> for example, u...@foo.com forwards to u...@bar.com, and u...@bar.com forwards 
> back to u...@foo.com, this will be a loop.
> 
> so how postfix find and stop this behavior?

By limiting the "hop count" (count of Received headers) and by checking
"Delivered-To:" headers added as part of indirect (aliases, ...)
local(8) delivery.

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


[pfx] Re: choose relay host for specific messages based on several headers and not envelope

2023-06-12 Thread Viktor Dukhovni via Postfix-users
On Mon, Jun 12, 2023 at 11:25:52AM +0200, spi via Postfix-users wrote:

> > To what end do various users need separate outbound relay hosts?
>
> For some of the aliases I am not the authoritive mail server.

How does the mail end up delivered to your system?

> >> Sieve vacation creates an ooo reply with an empty MAIL FROM which
> >> then postfix tries to deliver directly to the receiving MX - which
> >> in my case ignores my relay hosts and therefore fails.
> >
> > Why does this fail?  What's wrong with delivering the notifications via
> > the default relay or direct to the remote domain's MX?
>
> For some of the aliases I am not the authoritive mail server.

But the null sender isn't one of those "aliases", so why does mail
with a null sender need to transit through a particular relay?

Is DMARC/DKIM the concern?  Can't the "authoritative" domains that
forward mail to you for storage delegate a DKIM selector and associated
key to your system, so you don't need to relay through their servers?

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


[pfx] Re: choose relay host for specific messages based on several headers and not envelope

2023-06-12 Thread spi via Postfix-users

On Sun, Jun 11, 2023 at 11:28:46AM +0200, spi via Postfix-users wrote:

My users have a local mail address user@internal.local with different
aliases (virtual_mailbox_maps, virtual_alias_maps). Receiving and
sending mails through different relay hosts (am using
sender_dependent_relayhost_maps) works without issues. As MDA I use
dovecot with lmtp transport.

To what end do various users need separate outbound relay hosts?

For some of the aliases I am not the authoritive mail server.

Sieve vacation creates an ooo reply with an empty MAIL FROM which then
postfix tries to deliver directly to the receiving MX - which in my case
ignores my relay hosts and therefore fails.

Why does this fail?  What's wrong with delivering the notifications via
the default relay or direct to the remote domain's MX?

For some of the aliases I am not the authoritive mail server.

Perhaps instead of trying to direct null sender messages via per-user
relays, some simplification of your design might avoid the problem
entirely?


It's not that simple to change the design but it kept me thinking. What
I did is to configure the relay for the most used aliases as "relayhost"
rather then in "sender_dependent_relayhost_maps". Now most users can
send vacation replies from the most common alliases domains.

Thx so far!

Sebastian


--
Cheers
spi

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


[pfx] Re: SPF questions

2023-06-12 Thread Peter via Postfix-users
Technically it's an invalid MX record because MX records must point to a 
hostname, not an IP address.


They are probably trying (but failing) to implement a null MX record:

https://www.rfc-editor.org/rfc/rfc7505


Peter


On 12/06/23 19:50, wesley--- via Postfix-users wrote:


Note there is also RFC 7505 "Null MX" where you simply add "IN MX 0 ." to
any DNS name you wish not to send or accept e-mail. (this is designed to
work around implicie MX records when A record is present).





I saw some domains have MX pointing to 127.0.0.1. what does this mean?

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

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


[pfx] Re: SPF questions

2023-06-12 Thread postfix--- via Postfix-users

I saw some domains have MX pointing to 127.0.0.1. what does this mean?


This will tell the sender of the email to connect to 127.0.0.1 which is itself. 
It will send the mail program chasing its own tail.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: SPF questions

2023-06-12 Thread Matus UHLAR - fantomas via Postfix-users

Note there is also RFC 7505 "Null MX" where you simply add "IN MX 0 ." to
any DNS name you wish not to send or accept e-mail. (this is designed to
work around implicie MX records when A record is present).


On 12.06.23 07:50, wesley--- via Postfix-users wrote:

I saw some domains have MX pointing to 127.0.0.1. what does this mean?


I guess it's an attempt to achieve the same.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: SPF questions

2023-06-12 Thread Matus UHLAR - fantomas via Postfix-users

Dnia 10.06.2023 o godz. 17:33:06 Gerd Hoerst via Postfix-users pisze:

my entry e.g.

   600 IN TXT    "v=spf1 a mx -all"

that mean all servers listet in MX enrties of my domain are allowed
to send emails from my domain

So if you receive an email from my domain which are not sent from
one of those servers you can (if you want) put them in spam


On 10.06.23 23:18, Jaroslaw Rafa via Postfix-users wrote:

The original question was about a very specific SPF record, where the only
entry is "-all".

This SPF should be treated specially, as it indicates clearly that the
domain owner does not intend to send any mail from this domain, ever.


Note there is also RFC 7505 "Null MX" where you simply add "IN MX 0 ." to 
any DNS name you wish not to send or accept e-mail.  (this is designed to 
work around implicie MX records when A record is present).



So I would say in this case the spam signal is much stronger than with any
other SPF record (ie. for domains that DO actually send mail), and
regardless of how you treat SPF failures from other domains, you SHOULD
reject mail from domains that have this specific type of SPF record (why
accept mail from a domain that is not supposed to send any mail at all?).


looks like spf-engine's pyspf-milter and policyd-spf-python support option 
"No_Mail = True" to explicitly reject mail in this case even if SPF is not

enforced.


However, this is a bit hard to do, as all existing SPF checking tools that I
know do not treat this particular type of SPF record specially and don't
distinguish SPF failure on this kind of record from SPF failure on any other
type of SPF record. I would love to have a SPF tool that would mark SPF
failure on a domain that has only "-all" as a special case, something like
"absolute failure" while all other failures are just a "failure". Then I
could reject messages that fail SPF "absolutely" and just ignore "normal"
SPF failures (as I don't intend to check SPF on incoming mail from "normal"
domains and don't actually do it now). However, I don't know any tool that
makes this distinction and I'm not desperate enough to write my own ;).


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org