[pfx] Re: distributed email system

[Wietse Venema via Postfix-users]

Jeff Peng via Postfix-users:
> On 2024-06-15 21:35, Wietse Venema via Postfix-users wrote:
> 
> > 
> > This is a bit off topic for Postfix, but a comnmon approach is to
> > shard a global database into regional ones and limit the impact of
> > outages. Some database systems support sharding out of the box (for
> > example, MongoDB, supported by Postfix 3.9 and later).
> > 
> 
> Hi Wietse,
> 
> what does it mean "sharding out of the box"?

"X supports Y out of the box" means epression that X has support
for Y built in.

Wietse

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Dan Mahoney via Postfix-users]

> On Jun 15, 2024, at 15:03, Wietse Venema via Postfix-users 
>  wrote:
> 
> One addendum about how to distinguish from root@mydomain
> from different hosts.
> 
> Dan Mahoney via Postfix-users:
>>> Use a virtual alias mapping from "r...@dayjob.org" to the collector
>>> email address.  This is a variation on
>>> 
>>> /usr/local/etc/postfix/main.cf:
>>>virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root
>>> 
>>> /local/etc/postfix/virtual-for-root:
>>>   r...@dayjob.org collector-u...@collector-host.dayjob.org
>>> 
>>> Run "postmap hash:/local/etc/postfix/virtual-for-root" after
>>> editing the file.
>>> 
>>> Instead of a hash: map you could use a networked table such as *SQL
>>> or LDAP.
>> 
>> This would still result in rootmail being from root@mydomain, not
>> root@myhostname -- regardless of the destination, which makes it
>> way more confusing to read.
> 
> I forgot to mention that FreeBSD daily/security/weekly/monthly email
> messages have the hostname in the Subject. Like this:
> 
>Subject: hostname.porcupine.org weekly run output
>Subject: hostname.porcupine.org daily run output
>Subject: hostname.porcupine.org daily security run output
> 
> They arrive in the same mailbox, and there is confusion about their
> provenance.

They do, yes, but cron messages generally do not, which is why I'm trying to 
solve for the more general problem.

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Wietse Venema via Postfix-users]

One addendum about how to distinguish from root@mydomain
from different hosts.

Dan Mahoney via Postfix-users:
> > Use a virtual alias mapping from "r...@dayjob.org" to the collector
> > email address.  This is a variation on
> > 
> > /usr/local/etc/postfix/main.cf:
> > virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root
> > 
> > /local/etc/postfix/virtual-for-root:
> >r...@dayjob.org collector-u...@collector-host.dayjob.org
> > 
> > Run "postmap hash:/local/etc/postfix/virtual-for-root" after
> > editing the file.
> > 
> > Instead of a hash: map you could use a networked table such as *SQL
> > or LDAP.
> 
> This would still result in rootmail being from root@mydomain, not
> root@myhostname -- regardless of the destination, which makes it
> way more confusing to read.

I forgot to mention that FreeBSD daily/security/weekly/monthly email
messages have the hostname in the Subject. Like this:

Subject: hostname.porcupine.org weekly run output
Subject: hostname.porcupine.org daily run output
Subject: hostname.porcupine.org daily security run output

They arrive in the same mailbox, and there is confusion about their
provenance.

> However, we would like our rootmail to respect our aliases file,
> which tells root to go to a specific mail destination on a specific
> box.

Set up a virtual alias

r...@dayjob.org root@localhost

or

r...@host.dayjob.orgroot@localhost

(which one depends on myorgin and masquerade_xxx settings).

The Postfix local delivery agent will then respect the local
aliases database.

Wietse
___
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: distributed email system

[Jeff Peng via Postfix-users]

On 2024-06-15 21:35, Wietse Venema via Postfix-users wrote:



This is a bit off topic for Postfix, but a comnmon approach is to
shard a global database into regional ones and limit the impact of
outages. Some database systems support sharding out of the box (for
example, MongoDB, supported by Postfix 3.9 and later).



Hi Wietse,

what does it mean "sharding out of the box"?

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Wietse Venema via Postfix-users]

Dan Mahoney via Postfix-users:
> > Use a virtual alias mapping from "r...@dayjob.org" to the collector
> > email address.  This is a variation on
> > 
> > /usr/local/etc/postfix/main.cf:
> > virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root
> > 
> > /local/etc/postfix/virtual-for-root:
> >r...@dayjob.org collector-u...@collector-host.dayjob.org
> > 
> > Run "postmap hash:/local/etc/postfix/virtual-for-root" after
> > editing the file.
> > 
> > Instead of a hash: map you could use a networked table such as *SQL
> > or LDAP.
> 
> This would still result in rootmail being from root@mydomain, not
> root@myhostname -- regardless of the destination, which makes it
> way more confusing to read.

> However, we would like our rootmail to respect our aliases file,
> which tells root to go to a specific mail destination on a specific
> box.

Set up a virtual alias

r...@dayjob.org root@localhost

or

r...@host.dayjob.orgroot@localhost

(which one depends on myorgin and masquerade_xxx settings).

The Postfix local delivery agent will then respect the local
aliases database.

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Dan Mahoney via Postfix-users]

> On Jun 15, 2024, at 06:19, Wietse Venema via Postfix-users 
>  wrote:
> 
> Dan Mahoney via Postfix-users:
>> Hello,
>> 
>> We currently have myorigin = $mydomain, and mydomain = dayjob.org
>> on one of our border MXes, which is also the outbound MX for our
>> whole organization.  We are a fairly large site with mxes in two
>> locations and many machines which send mail which may relay through
>> here.  Mydomain feels like the *correct* origin answer.
>> 
>> However, we would like our rootmail to respect our aliases file,
>> which tells root to go to a specific mail destination on a specific
>> box.
> 
> Use virtual_alias_maps, as shown below.
> 
>> FreeBSD by default sends all its nightly security checks and the
>> like to "root" (bareword), and we globally deploy an alias file
>> that reroutes this to a collector on a single machine, both for
>> our machines that run postfix, as well as our machines that run
>> more simple mailers like dma.  We'd like the expectations consistent
>> across the board.
> 
> Use a virtual alias mapping from "r...@dayjob.org" to the collector
> email address.  This is a variation on
> 
> /usr/local/etc/postfix/main.cf:
> virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root
> 
> /local/etc/postfix/virtual-for-root:
>r...@dayjob.org collector-u...@collector-host.dayjob.org
> 
> Run "postmap hash:/local/etc/postfix/virtual-for-root" after
> editing the file.
> 
> Instead of a hash: map you could use a networked table such as *SQL
> or LDAP.

This would still result in rootmail being from root@mydomain, not 
root@myhostname -- regardless of the destination, which makes it way more 
confusing to read.

If I send mail to root@localhost, it respects aliases and does the right thing. 
 If I send mail to "root", it does not, because it already hits our existing 
virtual_maps destination for r...@dayjob.org .  (That 
address reaches people, not a collector script.  Our cron handling script does 
eventually fall-through to those people if it doesn't match the usual cron 
stuff)

We are already setting masquerade_domains for our entire domain:

mydestination = $myhostname, localhost.$mydomain, post.dayjob.org, localhost
masquerade_domains = !lists.dayjob.org, dayjob.org 
masquerade_exceptions=root

So on every other system that just appends their hostname to rootmail, this 
already works, and we don't rewrite it.

So perhaps the masquerading covers most of the normal uses of 
myorigin=mydomain?  

What else is covered in the definition of "myorigin" when it says "domain that 
appears in mail that is posted on this machine"?

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

[pfx] Re: distributed email system

[Wietse Venema via Postfix-users]

Joachim Lindenberg via Postfix-users:
> sql databases optimize for consistency instead of availability.
> And even if you design your data model not to rely on joins, to
> use unique ids per node, and to replicate both directions or
> disallow writes on the slave, at least MariaDB failed on partitioning,
> and I didn't want or tried to use an database not supported by the
> application.
> Obviously you may get by without encountering issues for quite
> some time, and this unfortunately is true for many replication
> scenario recommendations.

This is a bit off topic for Postfix, but a comnmon approach is to
shard a global database into regional ones and limit the impact of
outages. Some database systems support sharding out of the box (for
example, MongoDB, supported by Postfix 3.9 and later).

Reportedly, 

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Viktor Dukhovni via Postfix-users]

On Sat, Jun 15, 2024 at 09:19:58AM -0400, Wietse Venema via Postfix-users wrote:

> > However, we would like our rootmail to respect our aliases file,
> > which tells root to go to a specific mail destination on a specific
> > box.
> 
> Use virtual_alias_maps, as shown below.

The null-client overview in MULTI_INSTANCE_README may also be helpful:

http://www.postfix.org/MULTI_INSTANCE_README.html#split

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

[pfx] Re: myorigin usage for ONLY unqualified addresses

[Wietse Venema via Postfix-users]

Dan Mahoney via Postfix-users:
> Hello,
> 
> We currently have myorigin = $mydomain, and mydomain = dayjob.org
> on one of our border MXes, which is also the outbound MX for our
> whole organization.  We are a fairly large site with mxes in two
> locations and many machines which send mail which may relay through
> here.  Mydomain feels like the *correct* origin answer.
> 
> However, we would like our rootmail to respect our aliases file,
> which tells root to go to a specific mail destination on a specific
> box.

Use virtual_alias_maps, as shown below.

> FreeBSD by default sends all its nightly security checks and the
> like to "root" (bareword), and we globally deploy an alias file
> that reroutes this to a collector on a single machine, both for
> our machines that run postfix, as well as our machines that run
> more simple mailers like dma.  We'd like the expectations consistent
> across the board.

Use a virtual alias mapping from "r...@dayjob.org" to the collector
email address.  This is a variation on

/usr/local/etc/postfix/main.cf:
 virtual_alias_maps = hash:/local/etc/postfix/virtual-for-root

/local/etc/postfix/virtual-for-root:
r...@dayjob.org collector-u...@collector-host.dayjob.org

Run "postmap hash:/local/etc/postfix/virtual-for-root" after
editing the file.

Instead of a hash: map you could use a networked table such as *SQL
or LDAP.

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

[pfx] Re: distributed email system

[Joachim Lindenberg via Postfix-users]

sql databases optimize for consistency instead of availability. And even if you 
design your data model not to rely on joins, to use unique ids per node, and to 
replicate both directions or disallow writes on the slave, at least MariaDB 
failed on partitioning, and I didn´t want or tried to use an database not 
supported by the application.
Obviously you may get by without encountering issues for quite some time, and 
this unfortunately is true for many replication scenario recommendations.
Cheers, Joachim


-Ursprüngliche Nachricht-
Von: Jeff Peng via Postfix-users  
Gesendet: Samstag, 15. Juni 2024 07:20
An: postfix user 
Betreff: [pfx] Re: distributed email system

On 2024-06-15 12:46, Jean-François Bachelet via Postfix-users wrote:
> Hello folks :)

> isn't it what sql databases replication is good for ?
> 

Replication becomes bad when network partition. ;) 
___
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: Fastest way to reject unwanted sender

[Viktor Dukhovni via Postfix-users]

On Sat, Jun 15, 2024 at 07:06:43PM +0800, Jeff Peng via Postfix-users wrote:
> On 2024-06-15 18:14, John Levine via Postfix-users wrote:
> > People I'm working with have a short list of addresses from which they
> > don't want to accept mail at all, and they'd like to reject as early
> > as possible without running it through anti-spam milters, ideally by
> > rejecting the SMTP MAIL FROM command. What's the best way to do this?
> > The list is short so if it has to be hand-edited into config files,
> > that's OK.
> > 
> > I'm not sure exactly why they want to do it this way but they have
> > been running mail systems for a long time (some of you surely know
> > them) and I assume they have sensible reasons.
> 
> I think postscreen can block them easily.

Actually, no, because postscreen typically does not look at the sender
address, generally, just the client IP address is considered.

No reason to post a vague guess, when a concrete approach was requested.

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

[pfx] Re: Fastest way to reject unwanted sender

[Matus UHLAR - fantomas via Postfix-users]

On 15.06.24 12:14, John Levine via Postfix-users wrote:

People I'm working with have a short list of addresses from which they
don't want to accept mail at all, and they'd like to reject as early
as possible without running it through anti-spam milters, ideally by
rejecting the SMTP MAIL FROM command. What's the best way to do this?
The list is short so if it has to be hand-edited into config files,
that's OK.

I'm not sure exactly why they want to do it this way but they have
been running mail systems for a long time (some of you surely know
them) and I assume they have sensible reasons.


Note that at SMTP level, you can reject senders globally, and recipients 
individually. 

Thus, if you reject mail from any sender, none of recipients will be able to 
get mail from that user.



If one of recipients wants to accept mail from a sender while another 
recipient doesn't, teoretically you can reject that sender at recipient 
level, but that complicates configuration (but it's possible).
This would mean that for single mail to more recipients, sendes gets 
accepted and different recipients get refused. 




--
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.
Nothing is fool-proof to a talented fool.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fastest way to reject unwanted sender

[Jeff Peng via Postfix-users]

On 2024-06-15 18:14, John Levine via Postfix-users wrote:

People I'm working with have a short list of addresses from which they
don't want to accept mail at all, and they'd like to reject as early
as possible without running it through anti-spam milters, ideally by
rejecting the SMTP MAIL FROM command. What's the best way to do this?
The list is short so if it has to be hand-edited into config files,
that's OK.

I'm not sure exactly why they want to do it this way but they have
been running mail systems for a long time (some of you surely know
them) and I assume they have sensible reasons.



I think postscreen can block them easily.

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

[pfx] Re: Fastest way to reject unwanted sender

[Viktor Dukhovni via Postfix-users]

On Sat, Jun 15, 2024 at 12:14:01PM +0200, John Levine via Postfix-users wrote:

> People I'm working with have a short list of addresses from which they
> don't want to accept mail at all, and they'd like to reject as early
> as possible without running it through anti-spam milters, ideally by
> rejecting the SMTP MAIL FROM command. What's the best way to do this?
> The list is short so if it has to be hand-edited into config files,
> that's OK.
> 
> I'm not sure exactly why they want to do it this way but they have
> been running mail systems for a long time (some of you surely know
> them) and I assume they have sensible reasons.

For very short lists, the simplest is:

main.cf:
thash = texthash:${config_directory}/
smtpd_sender_restrictions =
check_sender_access ${thash}blocked-senders

blocked-senders:
m...@example.com REJECT Stooges not accepted here
la...@example.com   REJECT Stooges not accepted here
cu...@example.com   REJECT Stooges not accepted here

This admits occasional editing of the list without having to touch
main.cf.  If the list is sufficiently static that bolting it into
main.cf is a sensible tradeoff, then:

main.cf:
smtpd_sender_restrictions =
check_sender_access inline:{
{ m...@example.com   = REJECT Stooges not accepted here },
{ la...@example.com = REJECT Stooges not accepted here },
{ cu...@example.com = REJECT Stooges not accepted here },
}

Of course you can also use any of the fancier dictionary types, putting
the data in LDAP, a SQL database, a CDB table, LMDB, ...

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

[pfx] Fastest way to reject unwanted sender

[John Levine via Postfix-users]

People I'm working with have a short list of addresses from which they
don't want to accept mail at all, and they'd like to reject as early
as possible without running it through anti-spam milters, ideally by
rejecting the SMTP MAIL FROM command. What's the best way to do this?
The list is short so if it has to be hand-edited into config files,
that's OK.

I'm not sure exactly why they want to do it this way but they have
been running mail systems for a long time (some of you surely know
them) and I assume they have sensible reasons.

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