[pfx] Re: Contradicting Postfix documentation

[Antonio Leding via Postfix-users]

OK - not gonna argue any of your ridiculous comments.  You’re likely 
just trolling the mailer for lulz or some such and therefore don’t 
deserve my or anyone else’s time…


Good luck chief - you’re gonna need it…

- - -

On 2 May 2023, at 21:12, Kolusion K via Postfix-users wrote:

I've been posting on this mailer for the past 2 days and I have posted 
my configuration file as we as my mail log which demonstrates a 
problem with Postix where it is using network interfaces it shouldn't 
be using, as per the documentation. This is the first time I have seen 
you here, so, perhaps you should STFU before telling me to crawl 
before run and RTFM.


Also, stop thinking Postfix is flawless. You are living in a fantasy 
land. Lots of pilots thought their autopilot software was flawless, 
too, only to end up being killed by it.



K




Sent: Wednesday, May 03, 2023 at 5:51 am
From: "Antonio Leding" 
To: "Kolusion K" 
Cc: "Kolusion K via Postfix-users" 
Subject: Re: [pfx] Contradicting Postfix documentation

This looks a network and config issue rather than any defect in PF be
that with the code or the docs...

I would highly recommend you crawl before you try running so with 
that

in mind, scale back your config to just use v4 and get that working.
Also, if you really want help on this mailer, post both your main and
master config files so the community understands exactly what your
system is cfg’d to do.  Otherwise, it is doubtful folks will wanna
spend the time especially when your position is that you don’t need 
to

put in the same effort we all have done - i.e. seeing value in RTFM.

I can truly say that in the 13+ years I’ve been using PF, all of 
the

config and operational issues I’ve had were covered in the docs…

- - -

On 2 May 2023, at 20:28, Kolusion K via Postfix-users wrote:


Disabling IPv6 probably isn't an acceptable workaround anyway. What
happens if both an IPv4 and IPv6 IP address is listed? Postfix may
still use other network interfaces not listed (IP addresses).

Changing the parameter name wouldn't be a bad idea either seeing
parameter values are actually IP addresses and not interface names, 
as

the parameter name suggests.

K




Sent: Wednesday, May 03, 2023 at 5:11 am
From: "Kolusion K via Postfix-users" 
To: postfix-users@postfix.org
Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix
documentation

Postfix needs to be patched so that the value of the 
inet_interfaces

parameter is obeyed regardless of whether or not IPv6 (or other IP
versions?) is enabled.

K




Sent: Wednesday, May 03, 2023 at 4:57 am
From: "Kolusion K via Postfix-users" 
To: "Viktor Dukhovni via Postfix-users" 


Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation

Its not naive, its a fact- Postfix is broken. The inet_interfaces
parameter is described in the documentation as making Postfix use
only the interfaces listed for the parameter. In reality, Postfix
ignores the parameter by using network interfaces that are not
listed.

There is nothing mentioned in the Postfix documentation under the
inet_interfaces parameter section that says the inet_interfaces
parameter is for IPv4 only and that it will not have an effect on
IPv6 interfaces. That claim is your fairy tale.


K




Sent: Tuesday, May 02, 2023 at 5:57 pm
From: "Viktor Dukhovni via Postfix-users"

To: postfix-users@postfix.org
Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix 
documentation


On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via
Postfix-users wrote:


Hang on a second... my Postfix is using a network interface that
is
not the one set with the inet_interfaces parameter. So, my
experience
is true- the inet_interfaces parameter has no effect.


No, it has exactly the documented effects, perhaps different from
your
naïve expectations for your particular use case.  This is not 
the

forum
to seek "validation", the most you can expect from this list is
technical help to configure Postfix to meet your stated
requirements.

- The IPv4 addresses listed in inet_interfaces have no effect
on
  the choice of outbound IPv6 address when IPv6 is enabled.

- When inet_interfaces list no IPv4 addresses other than
loopback
  addresses, or lists multiple non-loopback IPv4 addresses,
then
  inet_interfaces also has no effect on the choice of 
outbound

IPv4
  addresses.

- To be sure that a particular IPv4 or IPv6 source address is 
used,

  configure an explicit "smtp_bind_address" or
"smtp_bind_address6".
- To be sure that IPv6 is not used, set "inet_protocols = ipv4".
- To be sure that IPv4 is not used, set "inet_protocols = ipv6".

- If you have just one IPv4 address suitable for both sending and
  receiving mail, set it as the only IPv4 address in
inet_interfaces.
  You then don't need an explicit "smtp_bind_address", though an
  explicit setting may be sensible 

[pfx] Re: Contradicting Postfix documentation

[Antonio Leding via Postfix-users]

This looks a network and config issue rather than any defect in PF be 
that with the code or the docs...


I would highly recommend you crawl before you try running so with that 
in mind, scale back your config to just use v4 and get that working.  
Also, if you really want help on this mailer, post both your main and 
master config files so the community understands exactly what your 
system is cfg’d to do.  Otherwise, it is doubtful folks will wanna 
spend the time especially when your position is that you don’t need to 
put in the same effort we all have done - i.e. seeing value in RTFM.


I can truly say that in the 13+ years I’ve been using PF, all of the 
config and operational issues I’ve had were covered in the docs…


- - -

On 2 May 2023, at 20:28, Kolusion K via Postfix-users wrote:

Disabling IPv6 probably isn't an acceptable workaround anyway. What 
happens if both an IPv4 and IPv6 IP address is listed? Postfix may 
still use other network interfaces not listed (IP addresses).


Changing the parameter name wouldn't be a bad idea either seeing 
parameter values are actually IP addresses and not interface names, as 
the parameter name suggests.


K




Sent: Wednesday, May 03, 2023 at 5:11 am
From: "Kolusion K via Postfix-users" 
To: postfix-users@postfix.org
Subject: [pfx] Fw: Re: Fw: Re: Re: Contradicting Postfix 
documentation


Postfix needs to be patched so that the value of the inet_interfaces 
parameter is obeyed regardless of whether or not IPv6 (or other IP 
versions?) is enabled.


K




Sent: Wednesday, May 03, 2023 at 4:57 am
From: "Kolusion K via Postfix-users" 
To: "Viktor Dukhovni via Postfix-users" 
Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation

Its not naive, its a fact- Postfix is broken. The inet_interfaces 
parameter is described in the documentation as making Postfix use 
only the interfaces listed for the parameter. In reality, Postfix 
ignores the parameter by using network interfaces that are not 
listed.


There is nothing mentioned in the Postfix documentation under the 
inet_interfaces parameter section that says the inet_interfaces 
parameter is for IPv4 only and that it will not have an effect on 
IPv6 interfaces. That claim is your fairy tale.



K




Sent: Tuesday, May 02, 2023 at 5:57 pm
From: "Viktor Dukhovni via Postfix-users" 


To: postfix-users@postfix.org
Subject: [pfx] Re: Fw: Re: Re: Contradicting Postfix documentation

On Tue, May 02, 2023 at 04:45:13PM +0200, Kolusion K via 
Postfix-users wrote:


Hang on a second... my Postfix is using a network interface that 
is
not the one set with the inet_interfaces parameter. So, my 
experience

is true- the inet_interfaces parameter has no effect.


No, it has exactly the documented effects, perhaps different from 
your
naïve expectations for your particular use case.  This is not the 
forum

to seek "validation", the most you can expect from this list is
technical help to configure Postfix to meet your stated 
requirements.


- The IPv4 addresses listed in inet_interfaces have no effect 
on

  the choice of outbound IPv6 address when IPv6 is enabled.

- When inet_interfaces list no IPv4 addresses other than 
loopback
  addresses, or lists multiple non-loopback IPv4 addresses, 
then
  inet_interfaces also has no effect on the choice of outbound 
IPv4

  addresses.

- To be sure that a particular IPv4 or IPv6 source address is used,
  configure an explicit "smtp_bind_address" or 
"smtp_bind_address6".

- To be sure that IPv6 is not used, set "inet_protocols = ipv4".
- To be sure that IPv4 is not used, set "inet_protocols = ipv6".

- If you have just one IPv4 address suitable for both sending and
  receiving mail, set it as the only IPv4 address in 
inet_interfaces.

  You then don't need an explicit "smtp_bind_address", though an
  explicit setting may be sensible in some cases.
- If you have just one IPv6 address suitable for both sending and
  receiving mail, set it as the only IPv6 address in 
inet_interfaces.

  You then don't need an explicit "smtp_bind_address6", though an
  explicit setting may be sensible in some cases.
- In either case disable any protocol that is not at all suitable 
for

  receiving or sending email.

--
Viktor.
___
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

___
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___
Postfix-users 

[pfx] Re: Postfix refuses to accept email from video camera

[Antonio Leding via Postfix-users]

“…maybe you can change the Postfix settings so that he makes friends 
with this camera and successfully receives mail from it…”


PF already does this - in plain-text.  PF handles TLS\SSL properly so 
asking to have PF modified to accommodate a client’s old & outdated 
firmware seems a bit like the tail waggin’ the dog don’t you think?


- - -

On 15 Apr 2023, at 14:30, Oleksandr via Postfix-users wrote:


Viktor, hHow you have analyzed everything perfectly! :-)

Of course, I cannot influence the camera firmware, it is old and there 
are no new firmware.


But maybe you can change the Postfix settings so that he makes friends 
with this camera and successfully receives mail from it?


--

___
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: Test Post - Please Ignore

[Antonio Leding via Postfix-users]

Got it…

Also, just an FYI - But I’ve always been able to confirm my posts are 
working properly by reviewing the list archive.  Posts seem to appear 
almost as fast as received by the list members so typically a good way 
to verify everything is working ok…


Just my .02…

https://www.mail-archive.com/postfix-users@postfix.org/

- - -

On 22 Mar 2023, at 22:41, duluxoz via Postfix-users wrote:


Sorry Everyone, but I need to test if my posts are going through

Please ignore (or feel free to send me a confirmation)

Cheers

Dulux-Oz
___
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

Re: password security

[Antonio Leding]

“Well, if you believe that it's ok for you to use it.”

Not sure if you mean I’m being presumptuous (not intended) or actually 
that I would see value in using it - I think you meant the latter but 
again, not sure…(lol)


Anyway, I would see value in at least checking it out - seems 
interesting…


- - -

On 27 Apr 2022, at 9:52, Michael Ströder wrote:


On 4/27/22 18:39, Demi Marie Obenour wrote:

On 4/27/22 12:27, Michael Ströder wrote:

On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
I’m very interested in what options / solutions (if any) exist 
that allow
you to use a passwordless approach to authenticating your users 
against

imaps/pop3/smtps/submission services (tls encrypted of course)


one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via
public Internet.


Hard disagree; Kerberos is safe for use over the Internet.


Well, if you believe that it's ok for you to use it.

My personal preference is to avoid storing shared secrets in a 
directly accessible network services. And I'm saying this as somebody 
who tried hard to secure OATH-LDAP services (HOTP with Yubikey and 
OpenLDAP).


BTW: My doubts are not about the Kerberos crypto used. My doubts are 
rather about the many unknown security bugs in all the systems 
involved which might allow attackers to get hold of the shared 
secrets.


Ciao, Michael.

Re: password security

[Antonio Leding]

“On my personal to-do list is to implement a simple X.509-CA for 
issuing short-term client certs, with a CLI tool to directly manipulate 
Thunderbird and Firefox key/cert DB.”


As in you are planning to build such a suite and put up on GH for all of 
us to use as well???


If so, would love to learn of your progress in that realm…

- - -

On 27 Apr 2022, at 9:45, Michael Ströder wrote:


On 4/27/22 18:36, Viktor Dukhovni wrote:
On 27 Apr 2022, at 12:27 pm, Michael Ströder  
wrote:



one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via 
public Internet.


Suitability depends on the user base, ... my personal mail server
indeed supports SASL GSSAPI submission.  There are no users with
weak passwords.


Strictly speaking you would have to say SASL GSSAPI with Kerberos 5 
because...



Note also that in principle GSSAPI can support all sorts of novel
authentication mechanisms,


...you're of course right that GSSAPI is also a generic layer.


The layering of SASL over GSSAPI is somewhat redundant,


Agreed.

But my concern is rather that I would not connect my KDC to the 
Internet (for now leaving aside approaches like proxy KCM).


In general I'm leaning more towards using asymmetric keys for authc. 
On my personal to-do list is to implement a simple X.509-CA for 
issuing short-term client certs, with a CLI tool to directly 
manipulate Thunderbird and Firefox key/cert DB.


Ciao, Michael.

Re: password security

[Antonio Leding]

Good feedback - typically I’d have some comments but since we’ve 
wandered a fair bit off the reserve here, I will refrain.  If anyone 
wants to continue this at Reddit or somewhere else more appropo, let me 
know…


- - -

On 26 Apr 2022, at 11:56, Lefteris Tsintjelis wrote:


On 26/4/2022 20:11, Antonio Leding wrote:
“…I'm just saying it's [F2B] not a solution to modern brute-force 
attack on passwords/accounts….”


It’s actually staggering that you say this because of how 
incredibly inaccurate this statement is…


Presume someone goes brute-force against a PostFix server via v6 only 
- so tons of addresses at their disposal. And let’s also presume 
that the defender has F2B tuned to allow no more than 2 attempts.


We know that brute-force is all about attempts per unit time, right? 
Yes - ok, so then let’s presume the attacker tunes their stack with 
a very low TCP wait time - somewhere around 1s. OK, fine, so after 2 
rapid attempts, the attacker will get blocked and they will wait 1s 
before moving on to the next IP - rinse - repeat.


The reality here is the attacker is essentially stuck in the mud 
against F2B. And because they want to maximize their attempts per 
unit time, they will move on once they realize someone is actively 
blocking their traffic.


They never moved on from here

In my real-world use-case, I had over 200K daily password attempts 
prior to F2B and 2 weeks after implementation, that number dropped to 
below 1 per day.


1-2 per IP per day here. They adopt and tune accordingly. It has been 
happening and still does for many years now no matter what even with 
F2B. Even once a day coming from a few thousand IPs is still a few 
thousand attempts even with IP blocking set at 1 day blocking per IP.


Blocking an IP is the single cheapest most effective thing one can do 
re: undesired traffic. Are there “better” solutions? Sure but 
what is “best” is a subjective determination and always depends 
on the use-case. And for almost all use-cases, blocking IPs is a 
solid tool…


IP blocking is one of the best ways but F2B is limited to each 
firewall's capabilities and you deal with thousands of IPs. If you 
want something more permanent and use F2B then firewall will reach its 
limits sooner or later.


Changing the authentication method to anything that does not accept 
PLAIN TEXT may also be another good way to deal with it that may work. 
By doing that only I have actually seen some attacks to completely 
stop.


F2B is a nice but limited solution to this problem. The best way, I 
personally found so far besides the password authentication method, is 
by setting smtpd_delay_reject to no (very important this step) and use 
my own home made and maintained DNSBL service as early as possible to 
restrict those attacks in a very permanent way from a few mail servers 
at the same time. CIDR blocking also works very well and fast with 
DNSBL in case of net blocks and huge IP blocks like IPv6 or IPv4 even 
and you also have central management of the black/white list. This has 
the advantage that does not give any info to the attacker other than 
his IP is blocked and stops the attack as early as possible but also 
limits the possibilities of a successful attack down to almost 
nothing.


Lefteris

Re: password security

[Antonio Leding]

“…I'm just saying it's [F2B] not a solution to modern brute-force 
attack on passwords/accounts….”


It’s actually staggering that you say this because of how incredibly 
inaccurate this statement is…


Presume someone goes brute-force against a PostFix server via v6 only - 
so tons of addresses at their disposal.  And let’s also presume that 
the defender has F2B tuned to allow no more than 2 attempts.


We know that brute-force is all about attempts per unit time, right?  
Yes - ok, so then let’s presume the attacker tunes their stack with a 
very low TCP wait time - somewhere around 1s.  OK, fine, so after 2 
rapid attempts, the attacker will get blocked and they will wait 1s 
before moving on to the next IP - rinse - repeat.


The reality here is the attacker is essentially stuck in the mud against 
F2B.  And because they want to maximize their attempts per unit time, 
they will move on once they realize someone is actively blocking their 
traffic.


In my real-world use-case, I had over 200K daily password attempts prior 
to F2B and 2 weeks after implementation, that number dropped to below 1 
per day.


Blocking an IP is the single cheapest most effective thing one can do 
re: undesired traffic.  Are there “better” solutions?  Sure but what 
is “best” is a subjective determination and always depends on the 
use-case.  And for almost all use-cases, blocking IPs is a solid tool…


- - -

On 26 Apr 2022, at 4:09, pat...@patpro.net wrote:

April 26, 2022 12:16 PM, "Mauricio Tavares"  
wrote:



Please explain how certificate authentication is, as you said,
100% efficient against brute-force attacks.


No password = no possible brute-forced password.



If these 100s ou 1000s of IP addresses are sending each thousands of
connection requests a minute, isn't this a DDoS?


No it's probably not. And you are trying to change the question here, 
so that it matches the solution you advocate for. The day you'll 
experience a real DDoS, I'm pretty sure F2B will see absolutely 
nothing about it. You don't need to target an open port/service to 
DDoS a server, 99,99% of the time it's just a flood of packets putting 
your firewall on it's knees.
To put a nice example on the table: last time we had a huge DDoS at 
work, it was in 2014, we were flooded with peaks at more than 15Gbps 
of traffic (syn flood, ntp, etc.). It was intermittent and lasted 
about 3 weeks. Our operator had to drop/null route all traffic from 
outside Europe during 11 days to protect us. And it was the attack of 
just one angry guy through a pay-for-use DDoS service.


Brute-forcing passwords/account as nothing to do with DDoS. Purpose of 
brute(forcing password is gaining access to a service in order to 
exploit it (steal data, send spam, etc.). Purpose of DDoS is to render 
the service unavailable.


Unless you run postfix on a 10 years old Raspberry, it can handle the 
load. But again, I'm not rejecting Fail2Ban, as it can have some 
value. I'm just saying it's not a solution to modern brute-force 
attack on passwords/accounts. And on larger email systems it can even 
cost you more time in support (like when you get a legitimate shared 
IP address blacklisted).



patpro

Re: password security

[Antonio Leding]

I’m not really sure if you understand that F2B is just a set of 
scripts wrapped around iptables (a firewall) - but that’s all it is - 
the real-work is being done by iptables which can be very effective 
against DDoS. Plenty of articles, papers, etc. on this very topic so 
your assertion that F2B is ineffective against DDoS or other attacks is 
simply false and DOA…


- - -

On 26 Apr 2022, at 4:09, pat...@patpro.net wrote:

April 26, 2022 12:16 PM, "Mauricio Tavares"  
wrote:



Please explain how certificate authentication is, as you said,
100% efficient against brute-force attacks.


No password = no possible brute-forced password.



If these 100s ou 1000s of IP addresses are sending each thousands of
connection requests a minute, isn't this a DDoS?


No it's probably not. And you are trying to change the question here, 
so that it matches the solution you advocate for. The day you'll 
experience a real DDoS, I'm pretty sure F2B will see absolutely 
nothing about it. You don't need to target an open port/service to 
DDoS a server, 99,99% of the time it's just a flood of packets putting 
your firewall on it's knees.
To put a nice example on the table: last time we had a huge DDoS at 
work, it was in 2014, we were flooded with peaks at more than 15Gbps 
of traffic (syn flood, ntp, etc.). It was intermittent and lasted 
about 3 weeks. Our operator had to drop/null route all traffic from 
outside Europe during 11 days to protect us. And it was the attack of 
just one angry guy through a pay-for-use DDoS service.


Brute-forcing passwords/account as nothing to do with DDoS. Purpose of 
brute(forcing password is gaining access to a service in order to 
exploit it (steal data, send spam, etc.). Purpose of DDoS is to render 
the service unavailable.


Unless you run postfix on a 10 years old Raspberry, it can handle the 
load. But again, I'm not rejecting Fail2Ban, as it can have some 
value. I'm just saying it's not a solution to modern brute-force 
attack on passwords/accounts. And on larger email systems it can even 
cost you more time in support (like when you get a legitimate shared 
IP address blacklisted).



patpro

Re: password security

[Antonio Leding]

Anyone who thinks that F2B merely “quiets logs” unfortunately has no 
idea what F2B actually does…


- - -

On 25 Apr 2022, at 1:00, Laura Smith wrote:


Sent with ProtonMail secure email.
--- Original Message ---
On Monday, April 25th, 2022 at 08:50, Dan Mahoney 
 wrote:


Even if fail2ban is “whack a mole”, you could also feed the data 
on auth spammers to an abuse-compaint script, and do your part to 
make the internet a little cleaner.


-Dan



And we all know how fabulously well abuse reports have worked with 
preventing spam, don't we !!


As I said. Fail2ban is a waste of time whack-a-mole.  Sure your logs 
might be quieter, but quieter logs does not equal better security !

Re: password security

[Antonio Leding]

I’ve been using F2B for over 4-5 years and it’s fantastic.  F2B is 
just one of many very useful tools in the belt of any  knowledgable 
infosec practitioner.  To consider F2B as “only for the lazy” speaks 
more to a lack of truly understanding infosec than it does of the tool 
itself…


- - -

On 25 Apr 2022, at 0:07, Laura Smith wrote:


--- Original Message ---
On Monday, April 25th, 2022 at 05:26, ミユナ  
wrote:



do you know how to stop passwords from being brute-forced for a
mailserver? do you have any practical guide?



Simple. You've got two options:

a) Use strong passwords (and if you run an automated password changing 
system, enforce strong passwords)


b) Use client-certificate authentication

Stuff like fail2ban is for the lazy. You should be focusing on solving 
the underlying cause of the problem, i.e. using one of the two options 
above.


The problem with stuff like fail2ban is that you are basically playing 
whack-a-mole.  IP address blocking simply does not work 2022, 
attackers have too many options (i.e. they can hop between cloud 
providers, they can use IPv6 to give them massive ranges to play with 
etc. etc.).

Re: Why the name Postfix?

[Antonio Leding]

This lore is BEYOND cool and Wietse is legend…

- - -

On 27 Mar 2022, at 15:00, Wietse Venema wrote:


Viktor Dukhovni:

On Sun, Mar 27, 2022 at 09:08:53AM +0530, Amarjeet Anand wrote:


What?s the story behind choosing the name as ?Postfix??


One of the stories can be found here:

https://techmonitor.ai/technology/ibm_takes_on_sendmail_with_secure_mailer

...
IBM calls the new mail program Secure Mailer, but it is actually 
one and
the same as Postfix, which is the same product as VMailer. IBM?s 
lawyers

nixed the VMailer moniker because it was too similar to another
company?s product.
...

This sounds plausible.  As for why "Postfix" and not, say, 
"Platypus", I

don't know.


We tried a bunch of names for which I could register a domain name,
and each time the IBM naming authority would reject our choice.
Changing the name of a program is a lot of work; it is worse than
changing the name of the main character in a story.

Then we found out that a different IBM team had open-sourced their
PKIX code under an external name "Jonah". So we gave my code two
names: the approved internal name "IBM secure Mailer", and the
external name "Postfix". "post" was a different word for "mail",
and "fix" was for Sendmail, the inspiration for my efforts.

Wietse

Re: DANE but DNS Provider dont support this

[Antonio Leding]

Great info - thanks Viktor…

- - -

On 25 Jan 2022, at 9:43, Viktor Dukhovni wrote:

> On Tue, Jan 25, 2022 at 04:58:49PM +0000, Antonio Leding wrote:
>
>> When you say “operate my own DNS”, do you mean your own DNS severs
>> at your location or maybe you manage your own zones via a DNS provider,
>> ISP, etc.?  Or perhaps some other model of which I am not aware?
>
> Zone data, DNSSEC keys, primary and seconday server on my own and a
> friend's self-hosted/managed hardware.  Hurricane Electric provides
> some additional secondary DNS servers.
>
> My registrar is not involved in serving DNS for my domains beyond
> arranging for the requested NS records to appear in the .ORG zone.
>
> Hurricane Electric gets zone updates via AXFR/IXFR.
>
> -- 
> Viktor.

Re: DANE but DNS Provider dont support this

[Antonio Leding]

Hi Viktor - just curious…

When you say “operate my own DNS”, do you mean your own DNS severs 
at your location or maybe you manage your own zones via a DNS provider, 
ISP, etc.?  Or perhaps some other model of which I am not aware?


- - -

On 24 Jan 2022, at 23:19, Viktor Dukhovni wrote:


On Mon, Jan 24, 2022 at 10:29:26PM +0100, Maurizio Caloro wrote:


If your provider supports neither "TLSA" records, nor the generic
(unknown type) encoding, switch to a more competent DNS provider.


please, how did you solve this, also with an external provider, or 
running

this task on your own bind server?


Not surprisingly, I operate my own DNS.  But there are providers who 
do

allow you to publish any and all DNS records, not just specific ones
they've choosen to "support".  I don't have a list of these at my
fingertips.  When evaluating a potential DNS provider make sure
they don't restrict your ability to publish records of your choice.

If you want DNSSEC, avoid NameCheap, they've ignored a bug report 
about

incorrect denial of existence for over two years now.

Make your provider supports publication of resource records in RFC3597
form.

--
Viktor.

Re: https://www.postfix.org/ in trouble

[Antonio Leding]

Not sure if this is a question for the community or just the devs but 
one of the credos this user swears by is “If it isn’t broken, then 
don’t go fixin’ it…”


There’s this FUD out there that all sites MUST be https.  Of course I 
disagree with this sentiment but perhaps there is something I’m 
missing.


So, to the community:  What is gained by requiring postfix.org to use 
https?


- - -

On 6 Jan 2022, at 17:34, Nilo César Teixeira wrote:


Hi,

First message on this group, thanks for all good advice so far.

Regarding https, why not host Postfix website here:
https://pages.github.com/ ?

We could leverage auto https ideally, but perhaps for custom domain 
certbot

would be necessary haven't researched yet.


Em seg., 3 de jan. de 2022 11:29, Viktor Dukhovni <
postfix-us...@dukhovni.org> escreveu:


On Mon, Jan 03, 2022 at 03:19:36PM +0100, Jaap van Wingerde wrote:


try plaintext http: http://www.postfix.org/ currently works for me.


Firefox (with 'only-https' off, still redirects to https).


Then you've failed to completely turn off 'only-https'.  The pages at
"http://www.postfix.org/; load just fine with the latest Firefox 
95.0.2.


There's no imminent risk of browsers dropping HTTP support.  They 
just

flag the connection as "insecure".

--
Viktor.

Re: SMTP Relay

[Antonio Leding]

To assist with this further, either here or on another list 
(preferable), I wouuld need to understand what is meant by 
“endpoint” as well as a little more detail re: the packet paths…


- - -


On 2 Aug 2021, at 7:29, Eric Shields | Mass Transit Honchkrow wrote:


Hi again. I finally figured out that my firewall rules might be the
reason my connection times out. So when I send an email, it doesn't 
get

past the SYN_SENT stage of the TCP handshake. In addition, it does not
leave my NAT device.

I currently have my domain's DNS record pointing to the endpoint, but 
on
the computer itself, it is pointing to the private IP of the address. 
It

sends the private IP out rather than the WAN IP despite adding source
NAT rules.

I want the traffic to leave the NAT device and go to the endpoint, and
then go on its way. My IP is completely whitelisted so blacklist 
issues

do not exist.

Device Information:

WAN: Debian 10
NAT device: Debian 10.2 or LMDE4
Postfix Version (installed on NAT): 3.4.14-0+deb10u1
Auth type: Unix-style

Relevant Firewall rules:

# email-services
#Filter rules
:FORWARD ACCEPT [0:0]
-A ufw-user-input -p tcp -m tcp -m multiport -j ACCEPT --dports
25,143,465,587,993
#NAT rules
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
# SUBMISSION Outbound
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination
172.16.101.1:587
-A PREROUTING -p tcp -m tcp --dport 465 -j DNAT --to-destination
172.16.101.1:465
-A POSTROUTING -p tcp -m tcp -d {private_wg0_ip} --dport 587 -j SNAT
--to-source {public_VPS_ip}:587
-A POSTROUTING -p tcp -m tcp -d {private_wg0_ip} --dport 465 -j SNAT
--to-source {public_VPS_ip}:465
COMMIT

I also enabled ip4 forwarding under /etc/sysctl.conf.


I want traffic to leave my NAT and go to the endpoint device where my
internet is delivered. I currently use Wireguard as a NAT and the
endpoint is a VPS I rent. I looked at the tcpdump data and it seems my
traffic isn't leaving. An SMTP connection is made but it loops back.

TCPdump output:
tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 
bytes

10:09:43.109444 IP (tos 0x0, ttl 64, id 51796, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.47019 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x2420), seq 3402657479, win 2760, options
[mss 1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.109445 IP (tos 0x0, ttl 64, id 59342, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.48911 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x07cc), seq 3288894079, win 2760, options
[mss 1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.109471 IP (tos 0x0, ttl 64, id 14578, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.55325 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x4879), seq 2239524688, win 2760, options
[mss 1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.109486 IP (tos 0x0, ttl 64, id 49212, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.55569 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x9d28), seq 259559345, win 2760, options
[mss 1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.156084 IP (tos 0x0, ttl 63, id 51796, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.47019 > {private_wg0_ip}.submission: Flags [S],
cksum 0x77e4 (correct), seq 3402657479, win 2760, options [mss
1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.156111 IP (tos 0x0, ttl 63, id 59342, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.48911 > {private_wg0_ip}.submission: Flags [S],
cksum 0x5b90 (correct), seq 3288894079, win 2760, options [mss
1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:43.156121 IP (tos 0x0, ttl 63, id 14578, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.55325 > {private_wg0_ip}.submission: Flags [S],
cksum 0x9c3d (correct), seq 2239524688, win 2760, options [mss
1380,sackOK,TS val 3176264352 ecr 0,nop,wscale 0], length 0
10:09:47.365473 IP (tos 0x0, ttl 64, id 59343, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.48911 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0xf72b), seq 3288894079, win 2760, options
[mss 1380,sackOK,TS val 3176268608 ecr 0,nop,wscale 0], length 0
10:09:47.365474 IP (tos 0x0, ttl 64, id 49213, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.55569 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x8c88), seq 259559345, win 2760, options
[mss 1380,sackOK,TS val 3176268608 ecr 0,nop,wscale 0], length 0
10:09:47.365505 IP (tos 0x0, ttl 64, id 14579, offset 0, flags [DF],
proto TCP (6), length 60)
 {private_wg0_ip}.55325 > {public_VPS_ip}.submission: Flags [S],
cksum 0x761c (incorrect -> 0x37d9), seq 

Re: Manual Clarification

[Antonio Leding]

I have to admit that when I first saw this, it was also a bit confusing 
as I was equating this with typical packet and session timeouts at the 
network level.


What helped me better understand this was the phrase “one byte at a 
time” and then reading up on things like Slow Loris that Viktor 
included…


Just my .02…

- - -

On 15 Jul 2021, at 12:21, Viktor Dukhovni wrote:


On 15 Jul 2021, at 10:41 am, post...@ptld.com wrote:

"The time limit for sending a Postfix SMTP server response and for 
receiving a remote SMTP client request."



The amount of time that smtpd(8) is willing to wait for a network 
write
to write some data when writing a command-response, or for a network 
read

to return some data when reading an SMTP command.

As elaborated under:

http://www.postfix.org/postconf.5.html#smtpd_per_record_deadline

Change the behavior of the smtpd_timeout and 
smtpd_starttls_timeout

time limits, from a time limit per read or write system call,
to a time limit to send or receive a complete record (an SMTP
command line, SMTP response line, SMTP message content line,
or TLS protocol message). This limits the impact from hostile
peers that trickle data one byte at a time.

Thus the default timeout is per read or write, rather than the 
complete

requested operation.  With the deadline timer the timeout applies to
the entire I/O operation, possibly spanning multi reads or writes.

However, even then it is never the transmission of an entire message
body, rather it would be a logical data fragment, an SMTP command or
response, a body content line, a TLS protocol record, ... which
partly mitigates "Slowloris" attacks,

https://en.wikipedia.org/wiki/Slowloris_(computer_security)

meaningful progress must be made within the deadline timer, just
sending a few characters per 300s is not enough.

--
Viktor.

Re: Briteverify

[Antonio Leding]

"...complained to Amazon AWS about them to no avail...”

I’m not privy to your specific scenario but if you are using AWS to 
provide unmanaged cloud VM services, such as EC2, then why would you 
complain to AWS re: any EM issue such as spam, verification, etc.?  
That’s not their job - that’s the sysadmins job.


- - -

On 22 May 2021, at 12:41, David D. Scribner wrote:


On 5/22/21 7:41 AM, PGNet Dev wrote:

On 5/22/21 8:25 AM, Simon Wilson wrote:
What am I missing,as a commercial email verification service what 
are

they trying to validate?

...

Personally, I consider email-verification services parasites -- and
manage my server accordingly.


I fully agree, and have even complained to Amazon AWS about them to no
avail.


Postfix provides a _great_ set of tools to reject what you wish at
numerous transaction stages.  Add to that option to firewall-off IP
addresses -- and enjoy the silence.

Not a choice/action everyone is willing/able to make.


I also fully agree with this, too, and use Postfix to can their 
initial

tries (they usually make two attempts from two different IP addresses,
the first to a bogus user at the address, and the second to an "info" 
,
"admin" or "postmaster" at the address. To date here are the IPs used 
by

briteverify.com that I have marked to drop in my firewall...

## briteverify.com (Amazon AWS)
34.195.68.199
50.19.103.141
50.19.103.149
50.19.105.217
50.19.253.57
52.1.117.226
52.3.174.189
52.203.39.60
54.83.44.163
54.83.54.115
54.197.230.106
54.197.250.255
54.225.108.187
54.235.119.112
107.20.134.42
107.20.207.58
107.20.218.183
107.20.232.98
107.20.235.139
107.20.249.220
107.21.204.157
107.22.212.75
184.72.250.175
184.73.205.138

Re: Speaking of Firefox and HTTP^H^H^H^HFTP...

[Antonio Leding]

“…FTP lets me PUT files into a location…”

Maybe I’m not tracking this correctly but I’ve never even considered 
doing FTP upload in a browser - I just don’t see the benefit to going 
that route.  Seems to me there are far easier and more functional tools 
that do not require any script.


An example of the most basic - as someone mentioned earlier, we have 
Finder on macOS and for Windows, I’m pretty sure Windows Explorer 
supports FTP all the up to v10…


But as with most things app\OS related, to each their own - the 
“right” way is the one that works for you…


- - -

On 23 Apr 2021, at 13:58, Cooper, Robert A wrote:

Because FTP lets me PUT files into a location without the hassle of 
setting up some kind of upload script, where you have to filter and 
tinker with permissions, so that you don't allow a malicious 
executable to be uploaded that can simply be run by visiting said file 
in a browser?  Granted, a lot of that has been replaced by SFTP/SCP, 
but ftp is still useful.



RobertC



From: owner-postfix-us...@postfix.org 
 on behalf of Antonio Leding 


Sent: Friday, April 23, 2021 15:45
To: Wietse Venema
Cc: postfix-users@postfix.org
Subject: Re: Speaking of Firefox and HTTP^H^H^H^HFTP...


Exactly - I’ve always wondered why the fascination + hangup with FTP 
when one can just dump the exact same files into a directory (or even 
the same one) and serve it as http or https - a file is a file is a 
file - the protocol doesn’t care…




On 23 Apr 2021, at 7:58, Wietse Venema wrote:

Viktor Dukhovni:

I just updated Firefox to version 88, and now "ftp://; support is
disabled by default, and the plan is to remove support in Firefox 90.

I've re-enabled it, will have to enjoy it to the max while it lasts...

[ Wietse's upstream FTP site for Postfix source tarballs will soon no
longer be browser-accessible. :-( ]

Available since just about forever:
http://ftp.porcupine.org/mirrors/postfix-release/index.html<https://urldefense.com/v3/__http://ftp.porcupine.org/mirrors/postfix-release/index.html__;!!KwNVnqRv!S2gGW4fJWhVv8mPXV4eZ0vMtoTb52w_DJ4U4Cbq4WtCxdRm-n7cjyEgGbFyr3kTw$>

Wietse

Re: Speaking of Firefox and HTTP^H^H^H^HFTP...

[Antonio Leding]

Exactly - I’ve always wondered why the fascination + hangup with FTP 
when one can just dump the exact same files into a directory (or even 
the same one) and serve it as http or https - a file is a file is a file 
- the protocol doesn’t care…


- - -

On 23 Apr 2021, at 7:58, Wietse Venema wrote:


Viktor Dukhovni:

I just updated Firefox to version 88, and now "ftp://; support is
disabled by default, and the plan is to remove support in Firefox 90.

I've re-enabled it, will have to enjoy it to the max while it 
lasts...


[ Wietse's upstream FTP site for Postfix source tarballs will soon no
  longer be browser-accessible. :-( ]


Available since just about forever:
http://ftp.porcupine.org/mirrors/postfix-release/index.html

Wietse

Re: Certificate Postfix.org missing?

[Antonio Leding]

Another +1 that with vanilla FF v87 + macOS HS, the power is in the 
hands of the user (where it truly belongs) via a user-knob controlling 
whether or not FF complains about non-https…


- - -

 On 22 Apr 2021, at 10:51, Richard wrote:


Date: Thursday, April 22, 2021 19:26:57 +0200
From: Claus Assmann 

On Thu, Apr 22, 2021, John Levine wrote:

Nope, vanilla install on MacOS.

Not sure what your "vanilla install" is...

Firefox 88.0 on MacOS:
www.postfix.org
and
http://www.postfix.org/
show the web page just fine without a problem.

It would be nice if the people who write browsers don't try to force
their kind of "standards" on others... ("but you can get a free
cert" -- what happens when those browsers do not "accept" those
free certs anymore?)


The interaction one gets with firefox with a non-https site depends
on how one has set the "HTTPS-Only Mode" options at the bottom of the
privacy & security preferences. With it enabled I get a warning, but
can select to continue to the HTTP site. With it off I connect
without any warnings, but the lock in the URL bar has a line through
it.

Re: Certificate Postfix.org missing?

[Antonio Leding]

Perhaps I’m wrong here but I think Wietse meant www.postfix.org vs. 
just postfix.org — as in only the former exists…


- - -

On 21 Apr 2021, at 13:08, Jos Chrispijn wrote:


Wietse Venema:


There is neither a service at port 443, nor a postfix.org website.


You mean you don't authorize this site to use the Postfix name?
Don't understand, too cryptic.

Best, Jos

-- With both feet on the ground you can't make any step forward

Re: What am I missing here?

[Antonio Leding]

FWIW, I had very similar issues and implemented fail2ban with very tight 
parameters to essentially block offensive probing hosts.  I went from 
something around 75k probes per month down to less than 50.


Also, out of respect for our counterparts on this PF dedicated mailer, 
feel free to ping me directly to discuss F2B.


- Tony -

- - -

On 15 Mar 2021, at 13:23, Wietse Venema wrote:


Bill Cole:

On 15 Mar 2021, at 12:17, Viktor Dukhovni wrote:


You've enabled SASL with dovecot as a backend.  You could limit this
to
port 587 (enable SASL via master.cf only for the submission 
service),
and require TLS there.  It'll probably still get probed.  That's 
life

on the public Internet.


Not only "could" but for most systems, SHOULD. The primary purpose 
would
be to reduce your attack surface. You will still get some auth 
attempts

on the port 25 service, but far less than with SASL enabled and of
course there is zero potential for those attacks ever working. Since
auth attacks have mostly graduated from "brute force" (i.e. 
random-ish
guessing) to "credential stuffing" (trying user+password pairs known 
to

work somewhere else) it has become important to limit the ways
successful authentication can work to only what is necessary. In 
2021,
no one should need to do authenticated mail submission on port 25. 
You

also can gain simpler and clearer configuration for other sorts of
policy enforcement (e.g. spam control) by not having any need to make
exceptions for submission on port 25 (e.g. exemptions from  DNSBL 
and/or

spam filters for trusted networks.)


I agree. Don't enabls SASL AUTH (or any MUA-specific features) on
the MTA service (port 25), and Do give the Postfix submission and
smtps services their own set of smtpd_mumble_restrictions.

Wietse

Couple of questions re: IPBLs & DNSBLs

[Antonio Leding]

Hello all,

 1. Where to place IPBL\DNSBL rules

* Because the result of a hit against an IPBL\DNSBL is to REJECT, does 
it make sense to place these kind of rules earlier in the 
SMTPD_RESTRICTIONS eval chain (i.e. CLIENT) rather than later (i.e. 
RECIPIENT) as shown in the _Getting selective with SMTP access 
restriction lists_ section of the SMTPD_ACCESS_README document.


 2. Making hits against an IPBL\DNSBL advisory

* Will using **warn_if_reject** essentially just log, rather than 
REJECT, when an entry hits an IPBL\DNSBL?


* If so, does this apply to **(a)** the entire set of restrictions; 
**(b)** just the restriction list where cfg’d; **(c)** only the 
restriction that immediately follows **warn_if_reject**?
* If “C”, then can **warn_if_reject** be safely used in production 
(manpage indicates this is a “safety net for testing”)?


 * The reason I ask is, due to a large number of false positives, I 
would like to have any hits against Spamcop be advisory rather than 
dropping the conversation.


Thanks in advance…

Re: Getting my head around restriction lists

[Antonio Leding]

“Does this mean that a condition in smtpd_helo_restrcitiosn which 
triggers a "REJECT" will, upon entering RCPTO TO mode, result in the 
rejection with nothing else evaluated?”


Yes but it doesn’t matter in which of the 5 lists it is encountered.  
Once REJECT is encountered, all evaluation ends…


“If so, it sill makes sense to put them all in 
smtpd_recipient_restrictions”


Not necessarily - it will depend on how one structures their tests.  
Keeping them in separate lists affords one the option of PERMIT’ing 
several different sets of rules whereas as if all in RECIPIENT, then all 
processing stops as soon as the first PERMT, REJECT, or DEFER is 
encountered.  This is distinctly different PERMIT behavior vs. having 
them in separate lists.


- - -


On 10 Mar 2021, at 15:20, JF Mezei wrote:


On 2021-03-10 15:08, Noel Jones wrote:


This is incorrect. With the default smtpd_delay_reject=yes, all
evaluations are performed after the client sends RCPT TO.



Thanks for clarification.  Reading the docs of delay_reject brings up
another question:

"Wait until the RCPT TO command before evaluating
$smtpd_client_restrictions, $smtpd_helo_restrictions and
$smtpd_sender_restrictions"


Does this mean that a condition in smtpd_helo_restrcitiosn which
triggers a "REJECT" will, upon entering RCPTO TO mode, result in the
rejection with nothing else evaluated?

(aka: does the documentation have an implicit "in that order" after 
the

$smtpd_sender_restrictions" ?

If so, it sill makes sense to put them all in
smtpd_recipient_restrictions as you can be explicitely order the
excecution of tests from any of the phases in the order that suits you
(aka: permit a sender before the test for helo are done).

Recipient & relay restriction evaluation order; log nomenclature

[Antonio Leding]

Hello all - couple of questions…

 Q1: Recipient & relay restriction evaluation order

Regarding the evaluation order of the SMTPD_RECIPIENT & SMTPD_RELAY 
restriction lists, there have been a few message threads that discuss 
the disparity between the Postfix documentation and the actual behavior. 
 The docs say RELAY first but the actual behavior is RECIPIENT first 
and the reason given was for backwards compatibility.


So, a few questions:

* Can anyone confirm that the current behavior is actually required for 
backward compatibility?


* Are there any use-cases that state it is desirable to have RELAY 
eval’d first?
* If both methods are required, are there plans to **(a)** add an entry 
for this in the backwards-compatibility safety net; and\or **(b)** add a 
config knob to change the evaluation order?
* Aside from the above, are there plans to resolve the disparity between 
the docs and actual behavior?



 Q2: Log entry START & STOP discrepancy

When using higher verbosity logging, each stage of the restriction list 
evaluations are bookended with a set of START & STOP lines that help 
delineate the eval steps for a particular restriction list.  For 
example:


- - -

>>> END Sender address RESTRICTIONS <<<
>>> START Recipient address RESTRICTIONS <<<

Lots of log messages related to SMTPD_RECIPIENT_RESTRICTIONS evaluation

>>> END Recipient address RESTRICTIONS <<<
>>> START Recipient address RESTRICTIONS <<<

Lots of log messages related to SMTPD_RELAY_RESTRICTIONS evaluation

>>> END Recipient address RESTRICTIONS <<<
>>> CHECKING Recipient address VALIDATION MAPS <<<

- - -

Note in the above that the same START & STOP lines are listed for both 
the SMTPD_RECIPIENT & SMTPD_RELAY stages.  I also confirmed that there 
are no START & STOP lines that mention RELAY — only CLIENT, HELO, 
SENDER, & RECIPIENT.


This seems to be an error but would like to see what the community 
thinks here…

Getting my head around restriction lists

[Antonio Leding]

Hello all,

I’ve been digging into restriction lists a bit more and grinding away 
on the rationale between seperating restrictions across each of the 
first four lists (CLIENT, HELO, SENDER, & RECIPIENT) vs. just placing 
them all in RECIPIENT.


Let me also state that yes, I have read the SMTPD_ACCESS_README file - 
several times in fact - and also spent a fair amount of time researching 
this in the mail-list archives.  My research & testing has led me to 
understand that regardless of which list issues a REJECT\DEFER, the 
result is the exact same — the message is denied.  There is no other 
implication related to the actual list that issued the REJECT\DEFER.


Therefore, the only rationale I can find to place restrictions in the 
separate lists is the following:


* The lists, taken as a group, operate as an AND for PERMIT purposes but 
an OR for REJECT\DEFER purposes.


* Therefore, with restrictions in each of the 4 lists, allowed messages 
must gather several PERMITs whereas denied messages need only gather 1 
REJECT\DEFER.
* Placing all of the rules in only the RECIPIENT list changes this model 
to become an OR for both PERMIT as well as REJECT\DEFER purposes.


Did I get this correctly?  Or am I horribly off-base and missing 
something more relevant here?


Thanks in advance for your feedback…

Re: Deprecated: white is better than black

[Antonio Leding]

Agreed — While my initial gut reaction is jump in and express myself 
directly about this change, my better angel (yes, I think I have only 
one) compels me to understand (a) this forum is not the right place to 
air any perspective for or against this change; (b) it’s done so get 
on with it.


This is just the most recent example of similar changes at GitHub and 
elsewhere that will all surely serve as examples of how society is 
struggling to address issues of race…


- - -

On 24 Feb 2021, at 10:44, Viktor Dukhovni wrote:


On Wed, Feb 24, 2021 at 07:29:18PM +0100, Jaroslaw Rafa wrote:


Postfix version 3.6 deprecates terminology that implies white is
better than black.


-1


FWIW, I also would not have made these changes, and personally think
they do more harm than good.  That said, the best thing at this point,
now that they've been made, is to just ignore them and move on.

People are free to choose to shape their language as they fit, so long
as they're not requiring me to do the same.  So long we all graciously
accept our various manners of speach, all's well.

--
Viktor.

Re: Multiple lookup entries in an SQL table

[Antonio Leding]

Thanks Dan & Weitse - very much appreciated…

- - -

On 19 Feb 2021, at 17:23, Dan Mahoney wrote:

From a database point of view, unless you have an ORDER BY statement 
in your query, the order returned could be either (unless postfix’s 
code is sorting them).


If postfix only wants a single result, then your query would need a 
LIMIT statement in it.


On Feb 19, 2021, at 5:19 PM, Wietse Venema  
wrote:


Antonio Leding:

Ok?

So if I have the following:

example.com OK
example.com REJECT

Then the correct Postfix lookup behavior is to return OK,REJECT


That is what the database client does.

However, there is no Postfix code that wants "OK,REJECT" as
a lookup result.

Wietse

Re: Multiple lookup entries in an SQL table

[Antonio Leding]

Ok…

So if I have the following:

example.com OK
example.com REJECT

Then the correct Postfix lookup behavior is to return OK,REJECT

Do I understand correctly?

Also, I do understand that this type of config would be a corner case 
and likely not really something to be used so this is really more 
negative testing…


- - -

On 19 Feb 2021, at 15:33, Viktor Dukhovni wrote:


On Fri, Feb 19, 2021 at 11:13:57PM +, Antonio Leding wrote:


I wanted to ask about the expected behavior if there are multiple
entries in an SQL table for the same lookup (IP address, network,
domain, etc.) which specify either the same or different actions
(REJECT, OK, etc.).


As documented, the LDAP, Posgresql and MySQL table drivers combine
multiple answers by intercalating commas between the individual 
values.
This works sensibly for e.g. returning multiple email addresses, but 
not

in contexts where comma-separated values are not expected.

It is your responsibility to write queries that return an answer that
conforms to the expected value syntax.

--
Viktor.

Multiple lookup entries in an SQL table

[Antonio Leding]

Hello Postfix Community,

I wanted to ask about the expected behavior if there are multiple 
entries in an SQL table for the same lookup (IP address, network, 
domain, etc.) which specify either the same or different actions 
(REJECT, OK, etc.).


- - -

 example #1

1.2.3.4 OK
1.2.3.4 REJECT

 example #2

example.com REJECT
example.com REJECT

 example #3

5.6.7.8 OK
5.6.7.8 OK

- - -

I know that access(5) states the specific search order for the various 
allowable lookup items but I did not find any discussion as to what 
happens when there is more than one identical searchable item entry.


Thanks in advance…

Re: Corner cases in SSL_shutdown.

[Antonio Leding]

You’re not doin’ well son…quit diggin’ and go back to rethink 
your approach.  I dare say at least a majority on this list, including 
myself, will trust Viktor et al a far bit more than someone coming in 
from the cold who freely admits the are not “well versed” in the 
app, nor a key protocol used by that app, but then still feels qualified 
to argue as to the (falsely) alleged flaws in that app…


Fingers crossed for ya’…

- - -

On 2 Feb 2021, at 8:09, Leo Bicknell wrote:

In a message written on Tue, Feb 02, 2021 at 10:56:04AM -0500, Viktor 
Dukhovni wrote:

well-intentioned work.  Fair enough, but ... the reality of the
situation is that what you perceive to be a bug is a carefully
considered feature, that optimises for keeping the MTAs limited
resources available for productive uses.


Limited resources?Nope, it's not 1993.

We're talking about, in the nominal case, one extra packet that
takes one extra RTT to show up.

Maybe you run your servers at 99.99% load, and that extra
0.01 will put them over the edge.  I can only tell you that I,
as one admin, would absolutely take the extra load to get proper
shutdown behavior.

If I need a mailer on my PDP/11 I'll be sure to consider postfix
for it's stingy use of resources. Does it compile on Unix version
6?  :)

--
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/

Re: bl.spamcop.net false positives

[Antonio Leding]

Great points - my view from earlier was that it really isn’t the 
registrar’s job to make sure someone’s doing is cfg’d properly.  I 
would much rather have the registrar take a more hand-off approach to 
configuring domains rather than the alternative.  Just imagine 
registrars who try and poke their nose into such things…


- - -

On 1 Feb 2021, at 14:21, Gerald Galster wrote:


That aside, IMHO, this is a huge screw-up for SC - not even in the
realm of acceptable…


On the other hand, why did the domain registrar put a blanket entry 
for
*.spamcop.net pointing to their server's IP when the domain expired 
instead of

just returning NXDOMAIN?


Because you can't make money with NXDOMAIN.

If a domain expired it's technically not your domain anymore.
A page with adverts can generate revenue while you have the chance
to get your domain reactivated. Some registrars chose to do it that 
way.


I don't like it but without that redemption period your domain
would be gone and most likely registered by a company that buys and 
sells

domain names. Getting it back would be much more expensive.

It depends on the registrars terms and conditions:

https://www.enom.com/kb/kb/kb_0402-what-happens-domain-expires.htm
https://sedo.com/us/about-us/news-press/newsroom/enom-partners-with-sedo-to-distribute-new-and-premium-internet-domain-names/

Best regards
Gerald

Re: bl.spamcop.net false positives

[Antonio Leding]

On the other hand, why did the domain registrar put a blanket entry 
for
*.spamcop.net pointing to their server's IP when the domain expired 
instead of

just returning NXDOMAIN?


Well, this could also have been a screw-up by SC and if so, I would view 
that as merely part of the same set of mistakes by SC…


- - -

On 1 Feb 2021, at 13:38, Jaroslaw Rafa wrote:


Dnia  1.02.2021 o godz. 20:31:51 Antonio Leding pisze:


That aside, IMHO, this is a huge screw-up for SC - not even in the
realm of acceptable…


On the other hand, why did the domain registrar put a blanket entry 
for
*.spamcop.net pointing to their server's IP when the domain expired 
instead of

just returning NXDOMAIN?
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once 
there

was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: CentOS Linux 8 is being practically abolished

[Antonio Leding]

100% agree that PF mailer is not the best place to discuss this so 
absent any other suggestion, does Reddit make sense?  Please let me know 
if anyone has picked up this discussion somewhere else…


Thanks…

- - -

On 9 Dec 2020, at 9:35, Viktor Dukhovni wrote:


I don't think this is the right forum for Linux advocacy.
It would perhaps be best if this thread moved elsewhere.

--
Viktor.

Fwd: Redirection using a 1:1 & domain wildcard alias

[Antonio Leding]

I found my answer - RFC-2821

- - -

Forwarded message:


From: Antonio Leding 
To: Jaroslaw Rafa 
Cc: postfix-users@postfix.org
Subject: Re: Redirection using a 1:1 & domain wildcard alias
Date: Mon, 5 Oct 2020 20:38:00 +

Thanks Jaroslaw,

Is any of this documented anywhere?  I’ve read virtual(5), 
virtual(8), cleanup(8), etc. ad nowhere in the observed behavior 
documented.


There’s discussion as to order to table searching and address 
matching but nothing that I’ve seen discusses what happens when 
there is both a user account and an alias configured nor when a user 
account and a domain wildcard alias are configured concurrently.


If this is all “just understood to be true”, then fine…but if 
so, would be far better to document this stuff…


On the flip side, if I’ve simply missed it, fair enough…just would 
like to know where…


- - -


On 5 Oct 2020, at 12:34, Jaroslaw Rafa wrote:


Dnia  5.10.2020 o godz. 17:28:04 Antonio Leding pisze:

* When both a 1:1 alias & a user are configured for a given email
address, why are emails sent to the alias\user only delivered to the
alias target?


Because that's exactly what aliases are meant for - to deliver mail 
to the

alias target *instead* of the original address.

If you want the mail to be delivered *both* to alias target and to 
the
original address, you must alias the original address to a *list* of 
both

these addresses (I don't know if it works for virtual_alias_maps, it
certainly works for aliases defined in /etc/aliases)


* When a domain wildcard alias & a user are configured, why are
emails sent to the user only delivered to the user and no copy to
the alias target?


Because domain wildcard alias applies *by definition* for any address 
in
the domain that *does not have* it's own alias defined. Once an 
address has

it's own alias defined, wildcard alias is ignored.
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once 
there

was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Redirection using a 1:1 & domain wildcard alias

[Antonio Leding]

Thanks Jaroslaw,

Is any of this documented anywhere?  I’ve read virtual(5), virtual(8), 
cleanup(8), etc. ad nowhere in the observed behavior documented.


There’s discussion as to order to table searching and address matching 
but nothing that I’ve seen discusses what happens when there is both a 
user account and an alias configured nor when a user account and a 
domain wildcard alias are configured concurrently.


If this is all “just understood to be true”, then fine…but if so, 
would be far better to document this stuff…


On the flip side, if I’ve simply missed it, fair enough…just would 
like to know where…


- - -


On 5 Oct 2020, at 12:34, Jaroslaw Rafa wrote:


Dnia  5.10.2020 o godz. 17:28:04 Antonio Leding pisze:

* When both a 1:1 alias & a user are configured for a given email
address, why are emails sent to the alias\user only delivered to the
alias target?


Because that's exactly what aliases are meant for - to deliver mail to 
the

alias target *instead* of the original address.

If you want the mail to be delivered *both* to alias target and to the
original address, you must alias the original address to a *list* of 
both

these addresses (I don't know if it works for virtual_alias_maps, it
certainly works for aliases defined in /etc/aliases)


* When a domain wildcard alias & a user are configured, why are
emails sent to the user only delivered to the user and no copy to
the alias target?


Because domain wildcard alias applies *by definition* for any address 
in
the domain that *does not have* it's own alias defined. Once an 
address has

it's own alias defined, wildcard alias is ignored.
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once 
there

was a Hushpuppy, and she lived with her daddy in the Bathtub."

Fwd: Redirection using a 1:1 & domain wildcard alias

[Antonio Leding]

I made an error in my statements below under **Observed behavior** - the 
last bullet point should read:


* Last, to verify that the domain wildcard alias works, emails sent to [ 
ANY_USER_OR_ALIAS_NOT_CFG’D ]_at_example.com are delivered to 
user1_at_exmaple.com just as I expected (W00T!!!). :=)


- - -

Forwarded message:


From: Antonio Leding 
To: Postfix users 
Subject: Redirection using a 1:1 & domain wildcard alias
Date: Mon, 5 Oct 2020 17:28:04 +

Hello Postfix Community,

First off, I apologize if answers to my questions are well-known but 
before posting, I did spend a fair amount of time researching all of 
the Postfix READMEs, HOWTOs, etc. to try and understand this but 
apparently I am not finding the right information.


Thanks in advance for your insights…

- - -

 The scenario:

* All domains, users, aliases, etc. are contained in SQL tables and 
defined in the main.cf as ‘virtual_mailbox_domains’, 
‘virtual_mailbox_maps’, etc.


* Two users are defined in the ‘virtual_mailbox_maps’ table.

 * user1_at_example.com
 * user2_at_example.com
* There are two aliases defined in the ‘virtual_alias_maps’ table:
 * user2_at_example.com —> user1_at_example.com
 * @example.com —> user1_at_example.com

 Observed behavior:

* If I send an email to user1_at_example.com, it is delivered as 
expected to the user1 mailbox.


* If I send an email to user2_at_example.com, because of the alias, it 
is also delivered to the user1 mailbox but not to the user2 mailbox.
 * I expected a copy of the email to also be delivered to the user2 
mailbox but it appears the alias prevents this and I’m not sure not 
sure why.
* However, if I remove the alias for user2, then emails sent to user2 
are delivered to the user2 mailbox (which makes sense) but nothing 
gets delivered to user1.
 * I expected the wildcard alias (@example.com) to cause a copy of the 
email to also be delivered to the user1 mailbox.
* Last, to verify that the domain wildcard alias works, emails sent to 
[ ANYTHING ]_at_example.com are delivered to user1_at_exmaple.com just 
as I expected (W00T!!!). :=)


 Recap:

* When both a 1:1 alias & a user are configured for a given email 
address, why are emails sent to the alias\user only delivered to the 
alias target?


* When a domain wildcard alias & a user are configured, why are emails 
sent to the user only delivered to the user and no copy to the alias 
target?

Redirection using a 1:1 & domain wildcard alias

[Antonio Leding]

Hello Postfix Community,

First off, I apologize if answers to my questions are well-known but 
before posting, I did spend a fair amount of time researching all of the 
Postfix READMEs, HOWTOs, etc. to try and understand this but apparently 
I am not finding the right information.


Thanks in advance for your insights…

- - -

 The scenario:

* All domains, users, aliases, etc. are contained in SQL tables and 
defined in the main.cf as ‘virtual_mailbox_domains’, 
‘virtual_mailbox_maps’, etc.


* Two users are defined in the ‘virtual_mailbox_maps’ table.

 * user1_at_example.com
 * user2_at_example.com
* There are two aliases defined in the ‘virtual_alias_maps’ table:
 * user2_at_example.com —> user1_at_example.com
 * @example.com —> user1_at_example.com

 Observed behavior:

* If I send an email to user1_at_example.com, it is delivered as 
expected to the user1 mailbox.


* If I send an email to user2_at_example.com, because of the alias, it 
is also delivered to the user1 mailbox but not to the user2 mailbox.
 * I expected a copy of the email to also be delivered to the user2 
mailbox but it appears the alias prevents this and I’m not sure not 
sure why.
* However, if I remove the alias for user2, then emails sent to user2 
are delivered to the user2 mailbox (which makes sense) but nothing gets 
delivered to user1.
 * I expected the wildcard alias (@example.com) to cause a copy of the 
email to also be delivered to the user1 mailbox.
* Last, to verify that the domain wildcard alias works, emails sent to [ 
ANYTHING ]_at_example.com are delivered to user1_at_exmaple.com just as 
I expected (W00T!!!). :=)


 Recap:

* When both a 1:1 alias & a user are configured for a given email 
address, why are emails sent to the alias\user only delivered to the 
alias target?


* When a domain wildcard alias & a user are configured, why are emails 
sent to the user only delivered to the user and no copy to the alias 
target?

Re: Very selective relay

[Antonio Leding]

Hi Viktor,

I never used this but am now curious — in reading the docs on this, it 
looks like the proper content in the “{ }” fields would be the IP or 
FQDN to\from one wishes to restrict traffic — do I have this correct?




On 18 Sep 2020, at 9:09, Viktor Dukhovni wrote:


On Fri, Sep 18, 2020 at 11:50:02AM +0200, Marek Kozlowski wrote:


I've been asked a very strange question. According to the best of my
knowledge there is no setting but maybe I'm wrong:

Is it possible the define a very selective relay according to the
following pseudo code:

/* a, b and c are set to some single values */
if (client's_IP==a)


smtpd_client_restrictions =
permit_auth_destination,
check_client_access inline:{ a=OK },
reject


 if (MAIL_FROM==b)


smtpd_sender_restrictions =
permit_auth_destination,
check_sender_access inline:{ b=OK },
reject


 if (RCPT_TO==c)


smtpd_recipient_restrictions =
permit_auth_destination,
check_recipient_access inline:{ c=OK },
reject

--
Viktor.

Re: postfix and MX

[Antonio Leding]

It’s important to differentiate between personal and professional use. 
 In the former, I agree email’s relevance & importance is diminishing 
largely due to social media and IM platforms.  But in the latter case, 
email will be with us for quite a long while…


- - -

On 18 Sep 2020, at 10:04, @lbutlr wrote:


On 17 Sep 2020, at 19:24, Amari CH  wrote:

Do you think if email will go to death in short future?


No, but it’s importance is already far less than it used to be. My 
kids (early 18 and 23) rarely check their email (a couple of times a 
week, and only if they are expecting something important) and that 
behavior is mirrored by their peers.


Even I use email far less than I used to, and nearly no personal 
communication happens over email anymore. Generally I get list mail, 
receipts for purchases, login verifications, status messages from 
servers, and that’s about it.


--
"Are you pondering what I'm pondering?"
"Uh, I think so Brain, but how are we gonna teach a goat to dance
with flippers on?"

Re: postfix and MX

[Antonio Leding]

dates back to April 201.  I would expect that 19 years is sufficient 
time

for the news to have reached Redmond, WA.


I think thats actually 1819 years so most definitely long enough to get 
the memo…


I stopped believing long ago that Microsoft adhered to any standard in 
earnest.  To me, they always seemed to be more about

implanting new standards that the world would then follow…


On 17 Sep 2020, at 18:11, Viktor Dukhovni wrote:


On Sep 17, 2020, at 9:30 PM, @lbutlr  wrote:

This may have changed, but I doubt it. If you do not have MX records
there are definitely mail servers out there that will not send mail
to you. Exchange for one at least used to refuse to deliver mail 
without
an MX record. I don't know if this is still the case as I am 
thankfully

at least 5 years from having to deal with anyone on Exchange server.


RFC 5321 was published 2008:

   https://tools.ietf.org/html/rfc5321#section-5.1

   The lookup first attempts to locate an MX record associated with 
the
   name.  If a CNAME record is found, the resulting name is processed 
as

   if it were the initial name.  If a non-existent domain error is
   returned, this situation MUST be reported as an error.  If a
   temporary error is returned, the message MUST be queued and retried
   later (see Section 4.5.4.1).  If an empty list of MXs is returned,
   the address is treated as if it was associated with an implicit MX
   RR, with a preference of 0, pointing to that host.  If MX records 
are
   present, but none of them are usable, or the implicit MX is 
unusable,

   this situation MUST be reported as an error.

But even prior to that:

   https://tools.ietf.org/html/rfc2821#section-5

   Once an SMTP client lexically identifies a domain to which mail 
will
   be delivered for processing (as described in sections 3.6 and 3.7), 
a

   DNS lookup MUST be performed to resolve the domain name [22].  The
   names are expected to be fully-qualified domain names (FQDNs):
   mechanisms for inferring FQDNs from partial names or local aliases
   are outside of this specification and, due to a history of 
problems,
   are generally discouraged.  The lookup first attempts to locate an 
MX
   record associated with the name.  If a CNAME record is found 
instead,

   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated 
as
   if it was associated with an implicit MX RR, with a preference of 
0,

   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" 
rule
   above applies only if there are no MX records present.  If MX 
records

   are present, but none of them are usable, this situation MUST be
   reported as an error.

dates back to April 201.  I would expect that 19 years is sufficient 
time

for the news to have reached Redmond, WA.

--
Viktor.

Re: postfix and MX

[Antonio Leding]

Just in case someone gets the wrong impression about MX records being
required...


TILT: MX records are not required for email to work — WOOT…

I’m sure most of this group already knew this but alas, I did 
not…One more gem of the many I have gathered from this mailer thus 
far…


Thanks Viktor… :=)



On 17 Sep 2020, at 13:59, Viktor Dukhovni wrote:

On Sep 17, 2020, at 12:43 PM, natan maciej milaszewski 
 wrote:


In e-mail incoming I need a MX restrictions - allow only domain who 
have

add MX in DNS - I known this is not RFC friendly ...


Just in case someone gets the wrong impression about MX records being
required...

It is more than "not RFC friendly", it is simply broken viz. the 
public

Internet.  Many legitimate sending domains have no MX records, this is
normal.  Refusing mail from non-MX domains does damage to the email
ecosystem.

It is difficult to imagine a situation where on the one hand you know
definitively that all the domains you'll be receiving email from have
MX records, and on the other hand you don't simply have a list of all
said domains, making the check for MX records moot.

--
Viktor.

Re: Feature suggestion: hook support for specific events?

[Antonio Leding]

Hi Phil, 

I presume you mean fail2ban here…if so, I must respectfully dissent… :=)

I agree that early on, the docs were horrible (to say the least) but more 
recently, I think the dev has done a fair job making f2b easier to implement 
and use.  

Now granted, I do only use it for checking SASL and making the approbate blocks 
but I was also able to extend f2b to add my own startup routine so, for 
example, my permaban list is setup when f2b is restarted.  Yes I know they do 
have a persistent db of sorts but I still prefer having my own permaban list...



> On Aug 26, 2020, at 1:48 PM, Phil Stracchino  wrote:
> 
> On 2020-08-26 16:03, Viktor Dukhovni wrote:
>> On Wed, Aug 26, 2020 at 09:59:34PM +0200, Jaroslaw Rafa wrote:
>> 
>>> Dnia 27.08.2020 o godz. 07:53:05 Peter pisze:
>>> 
>>> Or just use fail2ban.
>> 
>> Yes, but the whole point is that fail2ban is rather a hack, and NetBSD
>> actually has a decent framework for integrating application events
>> directly with the system firewall.
> 
> Not to mention that it has one of the more opaque and unclearly
> documented configuration schemes I've ever seen ...
> 
> This is why I keep thinking about writing my own single-purpose tool
> that does NOTHING BUT monitor mail.log for abusive IPs and remotely tell
> the firewall to banhammer them.
> 
> 
> -- 
>  Phil Stracchino
>  Babylon Communications
>  ph...@caerllewys.net
>  p...@co.ordinate.org
>  Landline: +1.603.293.8485
>  Mobile:   +1.603.998.6958

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Thanks Victor - actually watching some of the presos now…

BTW…any choice you like for DNSSEC providers?  Google seems like a safe bet but 
I figured you might have some feedback on this as well…



> On Jul 27, 2020, at 3:36 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 09:48:29PM +0000, Antonio Leding wrote:
> 
>> Again, great feedback…I am definitely diving into DANE now…may have
>> more questions but I will try to keep those to a minimum.
> 
> https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Again, great feedback…I am definitely diving into DANE now…may have more 
questions but I will try to keep those to a minimum.

Thanks again Victor - very much appreciated…


> On Jul 27, 2020, at 2:44 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 08:58:19PM +0000, Antonio Leding wrote:
>>> You can of course use an LE cert, it does not do any obvious harm,
>>> unless you also do DANE, and neither freeze the key, nor handle TLSA
>>> updates correctly (in advance of cert deployment).
>> 
>> So I’m gathering (a) not much will be gained by using a public-A
>> signed cert; and (b) the PROs of using DANE + self-signed likely (or
>> actually) outweigh going with an LE cert sans DANE.
> 
> Yes, (a) not much gained.
> 
> And, (b) while it is not in principle that difficult to combine DANE
> with automated renewal of Let's Encrypt certs, some struggle getting all
> the gears to move in unison.
> 
> If you do want to secure your inbound email, do consider DANE, but
> make sure that the first thing you implement is monitoring that
> checks whether DANE is working correctly, then a robust rollover
> process that ensures that even somewhat stale TLSA records (in
> secondary nameservers or downstream caches) never fail to
> match the deployed certificate chain.
> 
> Once you have monitoring, and sound rollover process, enable DANE.
> You'll of course need to have a DNSSEC-signed domain, and monitoring for
> that too (including checking that signatures on key RRsets are not
> unexpectedly close to expiring).
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).

So I’m gathering (a) not much will be gained by using a public-A signed cert; 
and (b) the PROs of using DANE + self-signed likely (or actually) outweigh 
going with an LE cert sans DANE.



> On Jul 27, 2020, at 1:52 PM, Viktor Dukhovni  
> wrote:
> 
> On Mon, Jul 27, 2020 at 07:32:41PM +, Antonio Leding wrote:
> 
>> I’ve always been dubious about the auth requirement by some (i.e. the
>> brain deads to which you refer) to allow TLS connections for
>> server-to-server communications.
> 
> Without DANE or (weaker) MTA-STS, indeed X.509 authentication of SMTP MX
> hosts is mere appearance of security.
> 
>> In any event, people do what people do so I guess in order to ensure
>> my server will employ the highest number of TLS sessions, I should use
>> a CA-signed cert...  
> 
> That's not the conclusion I reached.  My MTA uses a self-signed cert.
> The domains that abort STARTTLS with untrusted certs are few and don't
> send anything sensitive.
> 
>> Agreed?
> 
> You can of course use an LE cert, it does not do any obvious harm,
> unless you also do DANE, and neither freeze the key, nor handle TLSA
> updates correctly (in advance of cert deployment).
> 
> -- 
>Viktor.

Re: What is lost by using self-signed certs for TLS?

[Antonio Leding]

Hi Victor…

Thanks so much for the feedback…very helpful…

I’ve always been dubious about the auth requirement by some (i.e. the brain 
deads to which you refer) to allow TLS connections for server-to-server 
communications.  My view is this — when my server sends outbound mail, do I 
really care that the server I looked up via DNS is who they purport to be in 
the cert?  I have to imagine if a bad actor is able to somehow hack\forge DNS 
records that they will also be able to take care of the cert especially given 
that LE is free and very easy to obtain after the DNS has been cfg’d.

In any event, people do what people do so I guess in order to ensure my server 
will employ the highest number of TLS sessions, I should use a CA-signed 
cert...  

Agreed?


> On Jul 25, 2020, at 8:03 PM, Viktor Dukhovni  
> wrote:
> 
> On Sun, Jul 26, 2020 at 02:45:38AM +0000, Antonio Leding wrote:
> 
>> My goal is to fully understand what is lost by using only self-signed
>> certs on my PF server.  Here’s what I think I know:
>> 
>> — The fact that the cert is self-signed really only impacts mail
>> coming into our organization from those who are outside the
>> organization.
> 
> Assuming that no internal system fails to implement opportunistic TLS in
> a sane manner.
> 
>> — Because the cert cannot be verified, only anonymous ciphers can be
>> negotiated between my server and the other side’s client.
> 
> No. that's false.  A majority of clients will solicit certificates they
> then proceed to ignore.  It's to some extent a cargo-cult thing, someone
> on the Internet said that anonymous ciphers are insecure, and so users
> avoid them, though they don't exactly know why.  But the sickness is
> deep, TLS 1.3 has completely removed support for anonymous ciphers, so
> in a few years their use will be rather exotic.
> 
>> I have to believe there are more considerations here which of course
>> is why I came to you all…
> 
> A few brain-dead bulk mail systems (you probably don't care about),
> abort the TLS handshake when they see a certificate chain they can't
> verify, and then proceed to deliver in clear text, as though that's more
> secure than using unauthenticated TLS.  Again cargo-cult, someone on the
> Internet said that certificate verification is not optional.
> 
> Otherwise, you're free to use self-signed certs, they work just fine for
> quite a lot of receiving systems.
> 
> You can even implement DNSSEC for your domain (with monitoring to
> check that it is working, that signatures are not too close to
> expiration, ...) and then publish DANE TLSA records:
> 
>https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> but again only if you also implement monitoring to ensure that
> the certificate chain and TLSA records match, and a cert rollover
> process that avoids periodic outages caused by rolling the cert
> and TLSA RRs at the same time and ignoring remote caches, and/or
> older authoritative zone data on secondary servers.
> 
> -- 
>Viktor.

What is lost by using self-signed certs for TLS?

[Antonio Leding]

Hello all,

Please allow me to apologize in advance for any ignorance here…and also, I have 
researched and am just not seeing the entire picture here.

My goal is to fully understand what is lost by using only self-signed certs on 
my PF server.  Here’s what I think I know:

— The fact that the cert is self-signed really only impacts mail coming into 
our organization from those who are outside the organization.
— Because the cert cannot be verified, only anonymous ciphers can be negotiated 
between my server and the other side’s client.

I have to believe there are more considerations here which of course is why I 
came to you all…

OK - please educate as required…and as always many thanks in advance...

Re: Log entry timestamp

[Antonio Leding]

Thanks Wietse - rsyslog template it is then...

> On Jun 30, 2020, at 3:43 PM, Wietse Venema  wrote:
> 
> Antonio Leding:
>> Hello Postfix community,
>> 
>> Does anyone know if it is possible to configure, within Postfix,
>> the timestamp used for log messages?
>> 
>> I know I can setup a template in rsyslog but would rather do this
>> in Postfix if possible.
> 
> Postfix uses the syslog(3) API which has no date formatting.
> 
> Postfix built-in maillog_file logging behaves like syslog(3).
> 
>   Wietse

Log entry timestamp

[Antonio Leding]

Hello Postfix community,

Does anyone know if it is possible to configure, within Postfix, the timestamp 
used for log messages?

I know I can setup a template in rsyslog but would rather do this in Postfix if 
possible.

Thanks in advance...

— Tony —

Re: The historical roots of our computer terms

[Antonio Leding]

It goes without saying that this kind of a discussion\debate\etc. can easily 
turn into something wholly not intended…therefore, all I will offer is this…

Someone said earlier that they refuse to use select words because "words 
matter"…I would agree.  That said…

I respectfully submit that context matters far far more and ignoring that in a 
quest to find a solution to a widespread social ill and\or soothe a shared 
trauma is a very treacherous path.  Even the most serious and extreme social 
ills do not demand nor justify any and all measures and my hope is that any 
deliberative and collective body consider only those measures which have a 
bonafide goal of resolving whatever issue is at play.




> On Jun 6, 2020, at 10:46 AM, Wietse Venema  wrote:
> 
> Wietse Venema:
>> Ian Evans:
>>> Food for thought from the co-author of OAuth and oEmbed. How easy would it
>>> be for Postfix/Postscreen configs/docs to, say, refer to allow/deny lists?
>> 
>> Easily, if they can be acessed via DNSBL/DNSWL qeueries. Any 'new'
>> lookup mechanism will have to be added through a postscreen policy
>> plugin, and that involves new Postfix code.
>> 
>> For context: Postscreen decides if a remote SMTP client is allowed
>> to talk to a Postfix SMTP service. The decision is made on (protocol)
>> behavior and reputation, plus a static allow/deny list that is
>> typically populated with information from major provider SPF records.
> 
> I did not realize this was a suggestion to re-word Postfix documentation
> (and presumably, the corresponding program and parameter names).
> 
> Changing 'blacklist' into 'blocklist' or 'blackhole' into 'sinkhole'
> seems doable. There is no 'slave' in documentation, program names
> or parameter names. Internal identifiers and comments can be udpated
> with no visible consequence. Other changes would be difficult.
> 
>   Wietse

Re: may we suggest ICANN not run that many new tlds?

[Antonio Leding]

Demand is demand…it doesn’t matter from where it originates….



> On Nov 19, 2019, at 12:59 PM, Charles Sprickman  wrote:
> 
> 
>> On Nov 19, 2019, at 3:28 PM, Antonio Leding  wrote:
>> 
>> But I predict it will fall on deaf ears…
>> 
>> Suggesting this is tantamount to suggesting the PSTN not increase the # of 
>> area codes or NXX numbers.  Things like this are created as the demand 
>> grows…and due to the complete metamorphosis of the Internet over the last 
>> last 20 years, demand has definitely increased by at least a couple of 
>> orders of magnitude…
> 
> I think that’s the wrong analogy. In my web development work, I’ve never had 
> a client say, “hey, to protect my brand, I’d really like to buy 400 
> variations of my domain!”.
> 
> The demand here is all from registrars hoping to sell the same “domain” 50 
> times, it’s not coming from domain owners.
> 
> C
> 
>> 
>> 
>> 
>>> On Nov 19, 2019, at 12:23 PM, A. Schulze  wrote:
>>> 
>>> 
>>> 
>>> Am 19.11.19 um 10:58 schrieb Merrick:
>>>> may we suggest ICANN not open a new TLD anymore?
>>> yes, you can: https://www.icann.org/public-comments
>> 
> 

Re: may we suggest ICANN not run that many new tlds?

[Antonio Leding]

But I predict it will fall on deaf ears…

Suggesting this is tantamount to suggesting the PSTN not increase the # of area 
codes or NXX numbers.  Things like this are created as the demand grows…and due 
to the complete metamorphosis of the Internet over the last last 20 years, 
demand has definitely increased by at least a couple of orders of magnitude…



> On Nov 19, 2019, at 12:23 PM, A. Schulze  wrote:
> 
> 
> 
> Am 19.11.19 um 10:58 schrieb Merrick:
>> may we suggest ICANN not open a new TLD anymore?
> yes, you can: https://www.icann.org/public-comments

Re: ODMR/ATRN ?

[Antonio Leding]

Good luck…you’ll get it figured...  :=)


> On Jun 9, 2019, at 5:03 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message <14936220-5b2f-e44a-2f3a-5301e4153...@opendmz.com>, 
> cvandesa...@opendmz.com wrote:
> 
>> $ cat /etc/postfix/transport_maps
>> # Mail to anyone at opendmz.com is sent via SMTP to haproxy
>> opendmz.com smtp:haproxy:10025
>> 
>> The haproxy is an unnecessary layer of complication I added, but it
>> could just as easily be your home IP.
>> I'm using dynamic DNS in case my home IP changes, but it hasn't changed
>> in over 3 years now!
>> 
>> for example:
>> 
>> opendmz.com smtp:my-home-ip.dyndns.org:25
> 
> Wow!  My head is spinning!
> 
> I confess that I didn't "get it" at all when Wietse mentioned
> transport maps, but I *think* I am just starting to get it now.
> 
> So, basically, I can do what I want to do without even introducing
> the extra layer of complexity of -any- separate TCP proxy, yes?
> 
> Assuming so, this is getting easier and easier by the minute!
> 
> If all I really need to do is to put my own personalized version of
> the one-liner you posted (above) into /etc/postfix/transport_maps,
> then all I can say is "Thank you Postfix!!  Thank you Wietse!!"
> 
> I can't wait to try this.  I'm off now to do just that.  It'll take
> me awhile.  I have to buy a fresh new VM, install an OS and Postfix
> on it, set up dynamic DNS for my home machine, read up on how get my
> SOHO router to do this fancy-schamncy port forwarding thing (for SMTP
> traffic), configure and/or reconfigure two sets of Postfix .cf files,
> and then reboot everything in sight and run some tests.
> 
> Wish me luck.
> 
> 
> Regards,
> rfg

Re: ODMR/ATRN ?

[Antonio Leding]

Chris is the one who mentioned it (haproxy) and FWIW, based on the requirements 
you’ve stated in this thread, Chris’s setup seem to be pretty almost exactly 
what you want to do.

In case it got overlooked, I include the key EM here:



### BEGIN ###

I have 3 instances of postfix running (because I travel) but this can
work with 2.
1 server in the cloud, 2 locally one home one office.

The 2 local postfix instances only accept public email from the cloud
VM, but they accept local email (ipcam's, for example on the LAN).

The MX record points to the cloud VM, should it pass the spam test then
the 'clean' email is relayed to 1 of the 2 local postfix servers.
The local servers then deliver to a local Dovecot, where I access my
email from a local private IP on the LAN.

Think of the flow like this.

public email > Cloud VM (postscreen/rspamd test passes) > local Postfix
> local Dovecot.

Whichever local Dovecot received the message with replicate to the other
site.

I think of it this way, the email is coming from the public internet, so
scan it while it's out on the public internet.

If it passes the test, then it's considered 'good enough' to be
delivered to one of the local servers.

Internal email like ipcam's, server emails never leave the local LAN
(except to be replicated to the other local site).

Hope that makes sense.

Chris.

### END ###



> On Jun 9, 2019, at 4:46 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message <45mwkn2svqzj...@spike.porcupine.org>, 
> Wietse wrote:
> 
>>> Please clarify what I am missing if anything?
>> 
>> I understand that Ron wants to run Postfix on a static IP addres
>> in the cloud, but he does not want to store his email there, so
>> that rules out IMAP.
> 
> Yes. Exactly.
> 
> The more I think about this (transparent TCP/25 proxying) idea, the more
> I think it ought to work.  I just have to find teh Right proxy software.
> 
> Somebody mentioned haproxy and I'm looking at that now.  It might do the
> job.
> 
> The problem will be convincing it to dynamically -change- the one and only
> -other- IP address that it is proxying traffic to/from based on dynamic
> changes to some (dynamic) DNS FQDN.  If it can be coerced into doing that
> then I think this will work.
> 
> So anyway, that will be a total solution for the inbound side.  My outbound
> mail will have to be handled entirely separately.  For that, I'll have to
> use someone else's smarthost, or else roll my own, which is easy enough
> to do, I think.
> 
> If I get this all working, I'll have to do some modest write-up on it.
> I already have a title!
> 
>How To Run An SMTP Server on a Dynamic Line AND Get Away With It
> 
> :-)
> 
> 
> Regards,
> rfg

Re: ODMR/ATRN ?

[Antonio Leding]

I think you want this tool that Chris mentioned earlier…

http://www.haproxy.org 

> On Jun 9, 2019, at 4:13 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message <45mw9x6zlnzj...@spike.porcupine.org>, 
> Wietse Venema  wrote:
> 
>>> and then use something like fetchmail to poll that periodically to pull
>>> down all mail for my several domains and then have fetchmail re-inject
>>> all of those mail messages into the local Postfix.  The plan would be to
>>> get all this running and then give up my local static IP here, exchanging
>>> it for a dynamic one instead.  (This will save me a tiny bit of money on
>>> my monthy local ISP bill.)
>> 
>> What about setting up a tunnel between home (dynamic IP) and cloud
>> (static IP)? Could be a VPN, or SSH.
> 
> In a word, yea.  That exact light just came on over my little noggin.
> 
> If I can figure out how to make that work, I think that will be THE
> solution.
> 
> I just need to find some tool... some something... that will *transparently*
> proxy all of the inbound port 25 traffic that  comes in to the cloud VM
> server machine to some other IP address... some other IP address that
> will in fact be dynamic and changing, over time. (And yes, I understand
> that dynamic DNS is likely to be helpful here.)
> 
> So, what tool should I use to do this transparent TCP proxying?
> 
> I guess that I need to go a googling.
> 
> 
> Regards,
> rfg
> 
> 

Re: ODMR/ATRN ?

[Antonio Leding]

Couple things - last one first…

The static —> dynamic mapping…I would dig into what Wietse said earlier…VPN.  
If you merely want to have a static IP just act as basically a front-end for 
your local dynamic setup, then that’s the ticket…

As to the local errant could-tech imaging your HDD, totally agreed…but again, 
manageable via on-disk encryption…

Regardless, I understand your concern\fears re: putting that much faith in a 
location\hardware\people you cannot directly touch\manage\talk-to…makes total 
sense but as I’m sure you’d agree, we all have our varying levels of comfort 
and thresholds…




> On Jun 9, 2019, at 3:58 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message 
> <0100016b3e41b455-b95a3601-7822-4541-823a-6230f277bf1b-00@email.
> amazonses.com>, Antonio Leding wrote:
> 
>> Security:
>> 
>> With some VMs, you will have complete root-level rights on
>> the server and can do what you wish in terms of server security.
> 
> Yes.  Quite.  And believe me, I would -never- waste time on or trust in
> even the smallest way any VM that I DID NOT have root on.
> 
> I already do have one VM "slice", and yes, I do have root on that.
> 
> Traditionally, through the past 30+ years, and until quite recently, I've
> never placed -any- trust in any machine that I did not have immediate
> phsysical proximity to.  And even now, I still view remote cloud servers
> with great skepticism, security-wise.  The revelations, over that past
> year or so, of the multiple entire *waves* of x86 CPU security flaws...
> many of which still remain to be patched... have only underscored and
> reinforced my original skepticism.  Having root on a VM is hardly
> insurance against anything, and wasn't, even before anyone even knew
> about all of these CPU bugs.  How the hell do I know who has access
> to my storage volumes if they are in a data center a thousand miles
> away from me, being tended by people who I have never even met?
> 
> So I approach remote VMs very very cautiously, and unlike various
> corporations that have jumped headlong onto the cloud bandwagon with
> both feet, I personally put as little of my data as possible on such
> things. And even then, you won't catch me putting anything on there that
> would cause me real problems if the data were exposed to the entire
> planet.
> 
> Call me paranoid.  Call me a luddite.  But I sleep soundly at night.
> 
>> I understand - and share - your concerns re: cloud-based mail security
>> but those issues are manageable if proper infosec is implemented.
> 
> I disagree, and I believe that I even have evidence to the contrary.
> 
> Anybody working in that same data center, or who has either direct or
> remote admin access to the whole thing can image your entire drive
> anytime they want and perhaps without you even knowing that it
> happened.  We all hope that hosting company personnel won't go around
> doing this, willy nilly, or in lieu of a court order, but there are no
> guarrantees.
> 
> Even though I may disagree with you about the security of cloud VMs, I'm
> still very glad that you spoke up anyway, because you've made me think
> a bit more about the problem I'm trying to solve, and I've just realized
> that there may perhaps be a whole different way to skin this cat.
> 
> The bottom line is that really, I just want a (another) remote VM *only*
> (or primarily) for its static IP address... a static IP that's needed,
> generally although not necessarily absolutely, in order to run a mail
> server.
> 
> Sooo... maybe what I really should be trying to figure out is how
> I can run a -single- instance of Postfix, down here on my (soon to be
> dynamic) end-luser broadband line, and just set up a VM at some fixed
> IP address that will be running some sort of a VPN or something that
> will just be, in effect, transparently proxying all of the inbound port
> 25 traffic to my (soon to be dynamic) DSL line.
> 
> Will this work?  Is anybody doing this already?  If so, how do I set it
> all up?
> 
> 
> Regards,
> rfg

Re: ODMR/ATRN ?

[Antonio Leding]

Yeah - good stuff…I like it…

I checked out the haproxy site and am conjuring ways to put it to use…very 
cool...Thanks…


> On Jun 9, 2019, at 3:48 PM, cvandesa...@opendmz.com wrote:
> 
> Yeah exactly,
> 
> The local instances also don't need to listen on the standard TCP ports,
> since they are always only getting email from the cloud VM. So the
> firewalls whitelist the cloud VM's IP and the email is coming in via
> non-standard ports so I don't have a horde of botnets trying to deliver
> garbage to my local Postfix/Dovecot sites. The cloud VM gets the
> pleasure of dealing with that.
> 
> It's a little unusual but it's worked for me for a couple of years now. 
> Private DNS points "mail.opendmz.com" to a local IP, and public DNS
> points to the cloud where Haproxy is always listening and will proxy the
> IMAP connection back to one of the local sites (again, non-standard
> ports and whitelisted IP)
> 
> It's nowhere perfect but I don't know what is.
> 
> 
> On 09/06/2019 23:38, Antonio Leding wrote:
>> Just practicing the Au-rule…treat other as…  :=)
>> 
>> I would definitely agree NAT buys some security via obscurity…cheap, fairly 
>> easy, and does help to a degree.  So with the haproxy, am I understanding 
>> correctly that it will spin up (or already has running) IMAP back to your 
>> local site for when you’re say, on the Int’l Space Station, and need to get 
>> email?
>> 
>> Kinda cool...
>> 
>> 
>> 
>> 
>> 
>>> On Jun 9, 2019, at 3:31 PM, cvandesa...@opendmz.com wrote:
>>> 
>>> Ha be critical if you want, I don't mind at all :P
>>> 
>>> The main reason was reliability, as someone who's always
>>> breaking/rebuilding but also hosts their own email, I needed the email
>>> to spool somewhere in case I broke something for more than a few days.
>>> 
>>> The local PF boxes are behind home NAT connections with whichever
>>> firewall I felt like trying out at the time. More secure? I don't know
>>> maybe/hopefully?
>>> 
>>> Having the spam check done on the cloud for the same reasons. Every time
>>> I broke the server running the spam filter, it was like opening the
>>> flood gates :D
>>> 
>>> For flexibility there's another element I didn't bother to mention...
>>> 
>>> The same cloud VM runs haproxy which will loadbalance IMAPS connections
>>> back to either of the 2 local Dovecot sites. So I always have access to
>>> my email wherever I happen to find myself.
>>> 
>>> Chris.
>>> 
>>> 
>>> On 09/06/2019 23:19, Antonio Leding wrote:
>>>> Hi Chris,
>>>> 
>>>> Not being critical but really just want to understand why you architected 
>>>> it the way you did…
>>>> 
>>>> Are your local PF boxes behind a more secure border than your cloud based 
>>>> PF server?  I understand the SPAM part of the design — or I think I do :=) 
>>>> — it seems like you just feel more comfortable performing SPAM analysis in 
>>>> the cloud vs. inside your border…but curious in terms of other infosec…
>>>> 
>>>> Also, did you implement pinholes on your local side so you can access mail 
>>>> from different locations or just opt to not have that flexibility?
>>>> 
>>>> 
>>>> 
>>>>> On Jun 9, 2019, at 3:12 PM, cvandesa...@opendmz.com wrote:
>>>>> 
>>>>> Maybe something like I'm doing?
>>>>> 
>>>>> I have 3 instances of postfix running (because I travel) but this can
>>>>> work with 2.
>>>>> 1 server in the cloud, 2 locally one home one office.
>>>>> 
>>>>> The 2 local postfix instances only accept public email from the cloud
>>>>> VM, but they accept local email (ipcam's, for example on the LAN).
>>>>> 
>>>>> The MX record points to the cloud VM, should it pass the spam test then
>>>>> the 'clean' email is relayed to 1 of the 2 local postfix servers.
>>>>> The local servers then deliver to a local Dovecot, where I access my
>>>>> email from a local private IP on the LAN.
>>>>> 
>>>>> Think of the flow like this.
>>>>> 
>>>>> public email > Cloud VM (postscreen/rspamd test passes) > local Postfix
>>>>>> local Dovecot.
>>>>> Whichever local Dovecot received the message with replicate to the other
>>>>> site.
>>>>> 
>>

Re: ODMR/ATRN ?

[Antonio Leding]

Just practicing the Au-rule…treat other as…  :=)

I would definitely agree NAT buys some security via obscurity…cheap, fairly 
easy, and does help to a degree.  So with the haproxy, am I understanding 
correctly that it will spin up (or already has running) IMAP back to your local 
site for when you’re say, on the Int’l Space Station, and need to get email?

Kinda cool...





> On Jun 9, 2019, at 3:31 PM, cvandesa...@opendmz.com wrote:
> 
> Ha be critical if you want, I don't mind at all :P
> 
> The main reason was reliability, as someone who's always
> breaking/rebuilding but also hosts their own email, I needed the email
> to spool somewhere in case I broke something for more than a few days.
> 
> The local PF boxes are behind home NAT connections with whichever
> firewall I felt like trying out at the time. More secure? I don't know
> maybe/hopefully?
> 
> Having the spam check done on the cloud for the same reasons. Every time
> I broke the server running the spam filter, it was like opening the
> flood gates :D
> 
> For flexibility there's another element I didn't bother to mention...
> 
> The same cloud VM runs haproxy which will loadbalance IMAPS connections
> back to either of the 2 local Dovecot sites. So I always have access to
> my email wherever I happen to find myself.
> 
> Chris.
> 
> 
> On 09/06/2019 23:19, Antonio Leding wrote:
>> Hi Chris,
>> 
>> Not being critical but really just want to understand why you architected it 
>> the way you did…
>> 
>> Are your local PF boxes behind a more secure border than your cloud based PF 
>> server?  I understand the SPAM part of the design — or I think I do :=) — it 
>> seems like you just feel more comfortable performing SPAM analysis in the 
>> cloud vs. inside your border…but curious in terms of other infosec…
>> 
>> Also, did you implement pinholes on your local side so you can access mail 
>> from different locations or just opt to not have that flexibility?
>> 
>> 
>> 
>>> On Jun 9, 2019, at 3:12 PM, cvandesa...@opendmz.com wrote:
>>> 
>>> Maybe something like I'm doing?
>>> 
>>> I have 3 instances of postfix running (because I travel) but this can
>>> work with 2.
>>> 1 server in the cloud, 2 locally one home one office.
>>> 
>>> The 2 local postfix instances only accept public email from the cloud
>>> VM, but they accept local email (ipcam's, for example on the LAN).
>>> 
>>> The MX record points to the cloud VM, should it pass the spam test then
>>> the 'clean' email is relayed to 1 of the 2 local postfix servers.
>>> The local servers then deliver to a local Dovecot, where I access my
>>> email from a local private IP on the LAN.
>>> 
>>> Think of the flow like this.
>>> 
>>> public email > Cloud VM (postscreen/rspamd test passes) > local Postfix
>>>> local Dovecot.
>>> Whichever local Dovecot received the message with replicate to the other
>>> site.
>>> 
>>> I think of it this way, the email is coming from the public internet, so
>>> scan it while it's out on the public internet.
>>> 
>>> If it passes the test, then it's considered 'good enough' to be
>>> delivered to one of the local servers.
>>> 
>>> Internal email like ipcam's, server emails never leave the local LAN
>>> (except to be replicated to the other local site).
>>> 
>>> Hope that makes sense.
>>> 
>>> Chris.
>>> 
>>> 
>>> On 09/06/2019 23:00, Antonio Leding wrote:
>>>> AHHH - yes, thank you Paul - I did mean “cloud” based Postfix…
>>>> 
>>>> 
>>>> 
>>>>> On Jun 9, 2019, at 2:53 PM, Pau Amma  wrote:
>>>>> 
>>>>> On Sun, June 9, 2019 9:29 pm, Ronald F. Guilmette wrote:
>>>>>> In message
>>>>>> <0100016b3e069855-f95cf3e2-9649-4a55-8290-24a9d44f80cc-00@email.
>>>>>> amazonses.com>, Antonio Leding  wrote:
>>>>>> 
>>>>>>> Just curious any reason to not use use the could-based Postfix
>>>>>>> server + something like Dovecot and then have your clients access that
>>>>>>> directly?  I have this now for at least 20 domains and it works awesome.
>>>>>> Firstly, I have no idea what you mean by "could-based Postfix".  Was that
>>>>>> a typo?  What did you mean, actually?
>>>>> I'm guessing "could" is a typo (or perhaps autocorrection) for "cloud".
>>>>> 

Re: ODMR/ATRN ?

[Antonio Leding]

Just thinking out loud here but because you would want to harden the cloud 
server in any case, I’m not sure what having a VPN gets you if also using IMAPS 
and SMTP + SSL between the cloud and the client.  I guess one could argue that 
if you forget to set the SSL on the client side, you’re still covered but not 
seeing any other benefit.  

Please clarify what I am missing if anything…



> On Jun 9, 2019, at 3:29 PM, Wietse Venema  wrote:
> 
> Wietse Venema:
>> Ronald F. Guilmette:
>>> 
>>> I'd very much like to move my (Postfix) mail server, which currently resides
>>> on a (static IP) end-luser broadband line, to some VM in the cloud 
>>> someplace,
>>> and then use something like fetchmail to poll that periodically to pull
>>> down all mail for my several domains and then have fetchmail re-inject
>>> all of those mail messages into the local Postfix.  The plan would be to
>>> get all this running and then give up my local static IP here, exchanging
>>> it for a dynamic one instead.  (This will save me a tiny bit of money on
>>> my monthy local ISP bill.)
>> 
>> What about setting up a tunnel between home (dynamic IP) and cloud
>> (static IP)? Could be a VPN, or SSH.
> 
> Plus a transport_maps setting on the cloud side that routes mail
> into the tunnel.
> 
>   Wietse

Re: ODMR/ATRN ?

[Antonio Leding]

Hi Chris,

Not being critical but really just want to understand why you architected it 
the way you did…

Are your local PF boxes behind a more secure border than your cloud based PF 
server?  I understand the SPAM part of the design — or I think I do :=) — it 
seems like you just feel more comfortable performing SPAM analysis in the cloud 
vs. inside your border…but curious in terms of other infosec…

Also, did you implement pinholes on your local side so you can access mail from 
different locations or just opt to not have that flexibility?



> On Jun 9, 2019, at 3:12 PM, cvandesa...@opendmz.com wrote:
> 
> Maybe something like I'm doing?
> 
> I have 3 instances of postfix running (because I travel) but this can
> work with 2.
> 1 server in the cloud, 2 locally one home one office.
> 
> The 2 local postfix instances only accept public email from the cloud
> VM, but they accept local email (ipcam's, for example on the LAN).
> 
> The MX record points to the cloud VM, should it pass the spam test then
> the 'clean' email is relayed to 1 of the 2 local postfix servers.
> The local servers then deliver to a local Dovecot, where I access my
> email from a local private IP on the LAN.
> 
> Think of the flow like this.
> 
> public email > Cloud VM (postscreen/rspamd test passes) > local Postfix
>> local Dovecot.
> 
> Whichever local Dovecot received the message with replicate to the other
> site.
> 
> I think of it this way, the email is coming from the public internet, so
> scan it while it's out on the public internet.
> 
> If it passes the test, then it's considered 'good enough' to be
> delivered to one of the local servers.
> 
> Internal email like ipcam's, server emails never leave the local LAN
> (except to be replicated to the other local site).
> 
> Hope that makes sense.
> 
> Chris.
> 
> 
> On 09/06/2019 23:00, Antonio Leding wrote:
>> AHHH - yes, thank you Paul - I did mean “cloud” based Postfix…
>> 
>> 
>> 
>>> On Jun 9, 2019, at 2:53 PM, Pau Amma  wrote:
>>> 
>>> On Sun, June 9, 2019 9:29 pm, Ronald F. Guilmette wrote:
>>>> In message
>>>> <0100016b3e069855-f95cf3e2-9649-4a55-8290-24a9d44f80cc-00@email.
>>>> amazonses.com>, Antonio Leding  wrote:
>>>> 
>>>>> Just curious any reason to not use use the could-based Postfix
>>>>> server + something like Dovecot and then have your clients access that
>>>>> directly?  I have this now for at least 20 domains and it works awesome.
>>>> Firstly, I have no idea what you mean by "could-based Postfix".  Was that
>>>> a typo?  What did you mean, actually?
>>> I'm guessing "could" is a typo (or perhaps autocorrection) for "cloud".
>>> 

Re: ODMR/ATRN ?

[Antonio Leding]

AHHH - yes, thank you Paul - I did mean “cloud” based Postfix…



> On Jun 9, 2019, at 2:53 PM, Pau Amma  wrote:
> 
> On Sun, June 9, 2019 9:29 pm, Ronald F. Guilmette wrote:
>> 
>> In message
>> <0100016b3e069855-f95cf3e2-9649-4a55-8290-24a9d44f80cc-000000@email.
>> amazonses.com>, Antonio Leding  wrote:
>> 
>>> Just curious any reason to not use use the could-based Postfix
>>> server + something like Dovecot and then have your clients access that
>>> directly?  I have this now for at least 20 domains and it works awesome.
>> 
>> Firstly, I have no idea what you mean by "could-based Postfix".  Was that
>> a typo?  What did you mean, actually?
> 
> I'm guessing "could" is a typo (or perhaps autocorrection) for "cloud".
> 

Re: ODMR/ATRN ?

[Antonio Leding]

Hi rfg,

What did I mean by cloud-based postfix:

 —> When you said “…"to some VM in the cloud someplace…”, I did presume you 
meant a Postfix server in the cloud…like on an AWS VM or similar…

Security:

—> With some VMs, you will have complete root-level rights on the server and 
can do what you wish in terms of server security.  In terms of NW security, 
that will depend of course on the cloud\hosting provider that you happen to 
use.  I use AWS which gives me a lot of NW control…for example, I have a 
low-cost FW on the front end of my Postfix box and then I also do a few things 
locally on the actual server all coming together to provide security for my 
email infrastructure.

In terms of a accessing my email, I just configure IMAP on my client and point 
it to my Postfix + Dovecot server.  This is very similar to many email accounts 
one might setup using IMAP.  No local Postfix server or fetchmail required.  
Also, you do have the option of keeping the mail in the cloud or transfer it to 
your local machine.  In the latter case however, one thing you would lose is 
being able to access that mail from any device you wish.

I understand - and share - your concerns re: cloud-based mail security but 
those issues are manageable if proper infosec is implemented…


> On Jun 9, 2019, at 2:29 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message 
> <0100016b3e069855-f95cf3e2-9649-4a55-8290-24a9d44f80cc-00@email.
> amazonses.com>, Antonio Leding  wrote:
> 
>> Just curious any reason to not use use the could-based Postfix
>> server + something like Dovecot and then have your clients access that
>> directly?  I have this now for at least 20 domains and it works awesome.
> 
> Firstly, I have no idea what you mean by "could-based Postfix".  Was that
> a typo?  What did you mean, actually?
> 
> Secondly, in answer to what I think your question was... security.  I'm
> not keen to have -any- of my mail piling up for any lenth of time on some
> cloud server that I don't have complete and -physical- control over.
> Paranoid?  You bet.
> 
> My plan... if I can figure out a way to do it... will be to have a Postfix
> instance running on some cloud VM someplace (with static IP, of course)
> and use that for inbound and outbound (smarthost), and meanwhile set up
> something like fetchmail here on my home system to pull down all of the
> pending inbound message for all of my domains, say, every 120 seconds
> or so.  That way nothing will actually stay on the cloud server for very
> long, and if anyone manages to break into that, they won't find much in
> the way of my confidential emails, because the lifetime of each (stored)
> message there will typically be very very short.  (Maybe Hillary Clinton
> should have been so careful! :-)
> 
>> I'm not understanding why the need to relay the mail to your
>> local Postifix instance I'm sure there is a good reason 
>> but I'm just not seeing as yet
> 
> I have tried to explain my thought process.
> 
> Now that I have done so, I feel sure that someone will explain to me, very
> logically, why I am a blithering idiot.  That's OK, as long as I learn
> something in the process.
> 
> 
> Regards,
> rfg

Re: ODMR/ATRN ?

[Antonio Leding]

Hey rfg,

Just curious…any reason to not use use the could-based Postfix server + 
something like Dovecot and then have your clients access that directly?  I have 
this now for at least 20 domains and it works awesome.

I’m not understanding why the need to relay the mail to your local Postifix 
instance…I’m sure there is a good reason but I’m just not seeing as yet…




> On Jun 9, 2019, at 1:42 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> I'd very much like to move my (Postfix) mail server, which currently resides
> on a (static IP) end-luser broadband line, to some VM in the cloud someplace,
> and then use something like fetchmail to poll that periodically to pull
> down all mail for my several domains and then have fetchmail re-inject
> all of those mail messages into the local Postfix.  The plan would be to
> get all this running and then give up my local static IP here, exchanging
> it for a dynamic one instead.  (This will save me a tiny bit of money on
> my monthy local ISP bill.)
> 
> Googling for options just now, it sure sounds like ODMR/ATRN would fit
> my needs nicely, however I can't quite make out whether any of this
> ODMR/ATRN stuff has ever actually been implemented in Postfix or not.
> Has it been?
> 
> Regardless of whether it has or not, if anyone wants to suggest or recommend
> any alternative solution(s) I'm all ears.  I am open to anything that
> will get the job done.  My only real requirements for a solution are:
> 
>1)  Must support unlimited email addresses per each recipient domain.
> 
>2)  Must preserve envelope sender information.
> 
> In general, speed is not an issue, but security most certainly is.
> 
> That having been said, I am not eager to use Jakob Hirsh's odmrd because
> that SMTP server is written in Perl, and I've been known to be DDoS'd
> from time to time.  So I'm loath to leave anything written in Perl running
> on any outward facing port.  It's just way too easy for an attacker to
> run the CPU usage up to 100% and keep it there if one does so.
> 
> Looking forward to info on Postfix support for ODMR or alternatives thereto.
> 
> 
> Regards,
> rfg

Re: Forwarding received mail through AWS SES

[Antonio Leding]

Clarifying - I have both SES and EC2.  EC2 is my main postfix box but the SMTP 
side is a backup for SES which is my main outbound email…


> On Jan 19, 2019, at 7:16 PM, Antonio Leding  wrote:
> 
> FWIW - I’ve been using AWS for outbound SMTP well over 5 years with no 
> issues…maybe one-time have I bad an email rejected due to blacklisting…and 
> this was resolved within 30 minutes…
> 
> 
> 
>> On Jan 19, 2019, at 7:13 PM, Durga Prasad Malyala > <mailto:dp.maly...@gmail.com>> wrote:
>> 
>> 
>> On Sat, Jan 19, 2019, 23:26 Yasuhiro KIMURA > <mailto:y...@utahime.org> wrote:
>> From: Christos Chatzaras mailto:ch...@cretaforce.gr>>
>> Subject: Re: Forwarding received mail through AWS SES
>> Date: Sat, 19 Jan 2019 12:35:58 +0200
>> 
>> > AWS EC2 IPs may have low reputation to e-mail providers, so is not 
>> > recommended to send e-mails using these IPs.
>> > 
>> > Also AWS SES frequently have issues with RBLs. I wouldn't use it if you 
>> > use reliable delivery. It's good for newsletters because it has low cost 
>> > compared to other services and when you don't care if some e-mails are not 
>> > delivered.
>> > 
>> > My recommendation is to setup a VPS (from a company that has clean 
>> > network) with multiple IPs if you need to send a lot of messages and use 
>> > postfix relay with randmap to balance the outgoing messages between the 
>> > IPs.
>> 
>> Thank you for reply. Then I consider VPS instead of AWS EC2 and SES.
>> 
>> ---
>> Yasuhiro KIMURA
>> 
>> Correct. I would recommend linode or digitalocean any time over AWS SES. AWS 
>> is a good option for heavy transactional mail alerts etc. 
>> 
>> Cheers/DP
> 

Re: Forwarding received mail through AWS SES

[Antonio Leding]

FWIW - I’ve been using AWS for outbound SMTP well over 5 years with no 
issues…maybe one-time have I bad an email rejected due to blacklisting…and this 
was resolved within 30 minutes…



> On Jan 19, 2019, at 7:13 PM, Durga Prasad Malyala  
> wrote:
> 
> 
> On Sat, Jan 19, 2019, 23:26 Yasuhiro KIMURA   wrote:
> From: Christos Chatzaras mailto:ch...@cretaforce.gr>>
> Subject: Re: Forwarding received mail through AWS SES
> Date: Sat, 19 Jan 2019 12:35:58 +0200
> 
> > AWS EC2 IPs may have low reputation to e-mail providers, so is not 
> > recommended to send e-mails using these IPs.
> > 
> > Also AWS SES frequently have issues with RBLs. I wouldn't use it if you use 
> > reliable delivery. It's good for newsletters because it has low cost 
> > compared to other services and when you don't care if some e-mails are not 
> > delivered.
> > 
> > My recommendation is to setup a VPS (from a company that has clean network) 
> > with multiple IPs if you need to send a lot of messages and use postfix 
> > relay with randmap to balance the outgoing messages between the IPs.
> 
> Thank you for reply. Then I consider VPS instead of AWS EC2 and SES.
> 
> ---
> Yasuhiro KIMURA
> 
> Correct. I would recommend linode or digitalocean any time over AWS SES. AWS 
> is a good option for heavy transactional mail alerts etc. 
> 
> Cheers/DP