How to setup postfix for a limit set of sender and receive addresses plus local outbound?

[lcn2]

TL;DR

We need to setup postfix for a limited set of sender and receive addresses plus local outbound.

While @SirWumpus has gratefully agreed to work on this issue, others have asked us to describe the matter: if nothing else it may allow others such as yourself to join a discussion around any proposed solutions.

We are using a fairly recent postfix version 3.5.25, in case that matters.

In the description below, we will write with generic usernames, example domains and IP CIDR address blocks. This will be for illustration purposes only as these are not the actual values that will be used.

Requirements of the postfix configuration

We need a postfix configuration (/etc/post/fix.main.cf and related files) that has several properties. See below:

Ability to send out email to anywhere

We use the following lines in /etc/post/fix.main.cf today:

relayhost = [smtp.example.com]:465
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_wrappermode = yes

BTW: We need to send email to anywhere outside via the smtp.example.com host. The smtp.example.com host permits this, if any only if, we send via SASL over TCP port 465. The above main.cf lines are working well for us, now.

The /etc/postfix/saslpwd file contains a line of the following form:

[smtp.example.com]:465 someuser@example.com:a_password_example

FYI: we did a postmap /etc/postfix/saslpwd to form the /etc/postfix/saslpwd.db file that is used by postfix.

Email generated on the host can go to any local user

Email generated ON THE HOST (NOT from outside) can go to any local user, including any of those addresses referenced in /etc/aliases.

For example, applications such as cron that send email to a local administrator need to be able to do so.

BTW: We did a newaliases to form the /etc/aliases.db file that is used by postfix.

Inbound email connections are restricted

Inbound email connections (not from the local machine) may only come from IP addresses listed in /etc/postfix/connect_from.

The /etc/postfix/connect_from contains lines of the form:

# This is a comment
# These are just example CIDR blocks
192.168.1.0/24  OK
10.11.12.0/24   OK
10.9.8.7        OK

NOTE: We also have firewall(s) in place to also enforce restricted access to TCP port 25. The above requirement is an added "defense in depth" practice.

BTW: We did a postmap /etc/postfix/connect_from to form the /etc/postfix/connect_from.db file that is used by postfix.

Inbound sender email is restricted

For all Inbound email, the sender MUST (i.e., SMTP FROM address) be listed in /etc/postfix/sender_checks .

The /etc/postfix/sender_checks has lines of the form:

# This is a comment
# These are just example email addresses
user0@host0.example.edu OK
curds@whey.example.org  OK

FYI: We know that SMTP FROM addresses can be forged. This is a added "defense in depth" practice.

BTW: We did a postmap /etc/postfix/sender_checks to form the /etc/postfix/sender_checks.db file that is used by postfix.

The destination of all Inbound email is restricted

The destination of all Inbound email MUST be a LOCAL address / users listed in /etc/postfix/receiver_checks.

The /etc/postfix/receiver_checks has lines of the form:

# This is a comment
# These are the only destinations for inbound email
allowed0        OK
allowed1        OK
user2           OK

BTW: The /etc/aliases file has aliases that are a pipe for at least one of the allowed local users:

...
allowed0: | /usr/local/bin/prog
...

BTW: There are addresses in the /etc/aliases file that are NOT permitted destinations for inbound email. For example, in /etc/aliases file we have:

...
notallowed0: another0
notallowed1: | /usr/local/bin/prog2
...

Because notallowed0 and notallowed1 and another0 are NOT listed in /etc/postfix/receiver_checks as OK, inbound email to those addresses must NOT be allowed.

FYI: We did a postmap /etc/postfix/receiver_checks to form the /etc/postfix/receiver_checks.db file that is used by postfix.

A few more thoughts and summary

In the example files above where we show example lines, feel free to suggest changes such as foo REJECT or other modifications if/as needed.

There are no "normal" users on the system, just admins and IOCCC judges.

All outbound email is generated on the machine. This will be a combination of messages sent to people who have registered for the IOCCC28 (i.e., to almost anywhere) and special external addresses that IOCCC judges monitor for generated reports.

Inbound email, as you can see, is extremely restricted to some very specific IP addresses (/etc/postfix/connect_from.db), for email that is from some very specific SMTP FROM addresses (/etc/postfix/sender_checks.db) that are going to some very specific destinations (/etc/postfix/receiver_checks.db) that are LOCAL addresses of which one will be an aliases pipe (/etc/aliases.db). Nevertheless, not all addresses from /etc/aliases.db are allowed inbound email destinations.

The host must never relay email. It must only receive inbound email, under the above restrictions, to specific local addresses. Locally generated email may go anywhere, to any local address or to any external address, however.

We know that SMTP FROM addresses can be forged. We restrict external inbound email from addresses as an added "defense in depth" practice.

Email generated on the machine (such as via cron job or via some command) may go to any valid local addresses (such as root or some admin username), however ALL Inbound email is restricted to connections from specific IP addresses (/etc/postfix/connect_from.db), and from specific email senders (/etc/postfix/sender_checks.db) and going to very select local email addresses (/etc/postfix/receiver_checks.db).

We will have firewalls (and other things) that restrict network traffic. We will also limit inbound connections to TCP port 25 via the firewall. We want postfix, as a defense on depth, to further restrict inbound email sources by IP address.

We have maintained postfix systems before; however we do not have time to configure this specific use case as we are finishing an application that is critical to the opening of IOCCC28. That is why we are asking for others to help us with these postfix configuration requirements.

Thank you for your time and consideration.

— The IOCCC Judges

UPDATE 0

The above message also surely contains things that we need to correct. When we have corrected (most) of them, we will update this sentence. :-)

[xexyl]

A lot of this I have on my postfix config btw. I can try and look at it later I hope.

[lcn2]

A lot of this I have on my postfix config btw. I can try and look at it later I hope.

Thanks in advance for your time and consideration of this matter as well.

We look forward to what @SirWumpus, along with others such as yourself, suggest.

[xexyl]

A lot of this I have on my postfix config btw. I can try and look at it later I hope.

Thanks in advance for your time and consideration of this matter as well.

We look forward to what @SirWumpus, along with others such as yourself, suggest.

Sure. I have a question before I do more. I'm having a hard time seeing right now and I will be getting some food soon and I'm trying to get some fixes and enhancements in jparse (for mkiocccentry but it'll also be useful for the upcoming updates for chkentry(1)) and I also have some other things to do. So I probably won't get to reply today but it kind of depends. I'll ask the question in a new comment.

[xexyl]

FYI: with my tired eyes things seem reasonable. But as you know my vision is rubbish so you'll have to take that with a pinch of salt.

I do however have a question before I can proceed anyway.

QUESTION

By sending email to local users: do you mean delivering it to the local system mailbox ? Or can it be for example luser@example.com (where example.com is the MTA hostname - and restricted from being accessed obviously)?

Let me know and hopefully in the morn I can do more. Hoping to get some code in soon (almost done but one minor annoyance to fix). When that is done I can integrate it into mkiocccentry and if all good I can commit to both.

I do have other things I need to do though so the code might not come today.

[lcn2]

FYI: with my tired eyes things seem reasonable. But as you know my vision is rubbish so you'll have to take that with a pinch of salt.

I do however have a question before I can proceed anyway.

QUESTION

By sending email to local users: do you mean delivering it to the local system mailbox ? Or can it be for example luser@example.com (where example.com is the MTA hostname - and restricted from being accessed obviously)?

Let me know and hopefully in the morn I can do more. Hoping to get some code in soon (almost done but one minor annoyance to fix). When that is done I can integrate it into mkiocccentry and if all good I can commit to both.

Email sent from within the host can go anywhere, either to any external email address or some internal email address such as a mailbox or /etc/aliases address.

Email received from outside the host is restricted:

• inbound connection from a limited set of IP addresses (/etc/postfix/connect_from)
• SMTP FROM restricted to a limited set of email addresses (/etc/postfix/sender_checks)
• Email destination is restricted to a limited set of email addresses (/etc/postfix/receiver_checks)

We are looking for a proposed /etc/postifx/main.cf file plus any recommended mods to the above mentioned 3 files (such as perhaps some "* REJECT" line or format change or something).

[SirWumpus]

Question

@lcn2 Is this a public facing MX or is mail being relayed from the MX to an internal host (else where)? I assume the latter but just want to be sure.

[lcn2]

Question

@lcn2 Is this a public facing MX or is mail being relayed from the MX to an internal host (else where)? I assume the latter but just want to be sure.

Inbound email is to be relayed from a public email / IMAP / mail service only. The IP CIDR blocks of that service will be listed in the /etc/postfix/connect_from file. In order for the service to be able to deliver email, an MX record for the host will be published.

There is a public facing interface where postfix listens in TCP port 25. That interface has an internet routable IPv4 address (not a private IP address). And while the TCP port 25 is protected by firewall(s), as a "defense in depth", postfix should also restrict inbound IP connects via /etc/postfix/connect_from.

We hope this answers your question.

[xexyl]

FYI: with my tired eyes things seem reasonable. But as you know my vision is rubbish so you'll have to take that with a pinch of salt.
I do however have a question before I can proceed anyway.

QUESTION

By sending email to local users: do you mean delivering it to the local system mailbox ? Or can it be for example luser@example.com (where example.com is the MTA hostname - and restricted from being accessed obviously)?
Let me know and hopefully in the morn I can do more. Hoping to get some code in soon (almost done but one minor annoyance to fix). When that is done I can integrate it into mkiocccentry and if all good I can commit to both.

Email sent from within the host can go anywhere, either to any external email address or some internal email address such as a mailbox or /etc/aliases address.

Email received from outside the host is restricted:

• inbound connection from a limited set of IP addresses (/etc/postfix/connect_from)
• SMTP FROM restricted to a limited set of email addresses (/etc/postfix/sender_checks)
• Email destination is restricted to a limited set of email addresses (/etc/postfix/receiver_checks)

We are looking for a proposed /etc/postifx/main.cf file plus any recommended mods to the above mentioned 3 files (such as perhaps some "* REJECT" line or format change or something).

You know I have done user mailboxes before but since I seldom check them I just have them as an account. I could maybe look into how I did that if that would be helpful - though not today. As for the other stuff you have the right idea (and using postmap is important to help speed it along - but it is not required).

Since you've made progress: do you have a comment here that has what you have done so far (with this list)? If yes where is it so I can look at it? If not when you get a chance (I know you're super busy!) it might be helpful (maybe with examples - though perhaps you already gave some in the OP .. I know you did include something like it if not exactly).

[SirWumpus]

We are using a fairly recent postfix version 3.5.25, in case that matters.

I'm testing within my NetBSD VM which comes stock with 3.8.4 and an alternative package 3.9.1.

@lcn2 Are you using a fresh install of whatover_os?

In the config I'm working, I'm marking root elements like domain name, host, install paths with comments as what needs to change between TESTING and PRODUCTION when ready.

# PRODUCTION
#mydomain = ioccc.org
#postfix_dir = /etc/postfix

# TESTING
mydomain = snert.net
postfix_dir = /usr/pkg/etc/postfix

From that I'm trying to get the TLS to the relay host working. After I'll fine tune the other elements. TLS and DNS setup is always a pain; thankfully I had most of it done for home use with Sendmail.

[SirWumpus]

Aside: DNS for home systems (real iron or VMs) have several ways to setup their host entries

• predefine the host in DNS under your personal domain(s) - all fine till the ISP reassigns your home gateway router a new IP address (but for most it works for testing).
• longer term solution is use DDNS with BIND9 and have home system register themselves in under a subdomain of a personal domain eg. home.example.com is where to park a host like baka.home.example.com and it auto updates just in case you get a new IP address from the ISP (which happens sometimes).

Also one can use easyrsa to generate self-signed certs for internal use and/or testing WRT to the public facing mx.

[xexyl]

Aside: DNS for home systems (real iron or VMs) have several ways to setup their host entries

• predefine the host in DNS under your personal domain(s) - all fine till the ISP reassigns your home gateway router a new IP address (but for most it works for testing).
• longer term solution is use DDNS with BIND9 and have home system register themselves in under a subdomain of a personal domain eg. home.example.com is where to park a host like baka.home.example.com and it auto updates just in case you get a new IP address from the ISP (which happens sometimes).

Also one can use easyrsa to generate self-signed certs for internal use and/or testing WRT to the public facing mx.

Or run your own authoritative (preferably with a friend who has a slave DNS server for you) DNS server with a static IP (or static IP block) - with PTR delegation. That's what I do. I don't like dynamic DNS an it wouldn't work well.

I guess it works for some people but then you throw in MTAs and other things and it's not worth it.

As for self-signed I certs that works I guess but I just use Let's Encrypt. I wasn't keen on it for a while but I gave in. I just was not in favour of their ridiculous idea of having to run it as root (!!) - but I use something else as an unprivileged user so it works fine.

[SirWumpus]

Well the whole point is home system should run their mail through a public facing mail system to avoid having PTR is. Let's Encrypt is fine (never tried it, poor support on NetBSD). Anyway self-sign certs are just used for the TLS setup between home and the mail hub (both I control) so not important. All outbound mail relays via the mail hub, never directly from home since ISPs block outbound port 25 on residential accounts to prevent spammers.

[xexyl]

Well the whole point is home system should run their mail through a public facing mail system to avoid having PTR is. Let's Encrypt is fine (never tried it, poor support on NetBSD). Anyway self-sign certs are just used for the TLS setup between home and the mail hub (both I control) so not important. All outbound mail relays via the mail hub, never directly from home since ISPs block outbound port 25 on residential accounts to prevent spammers.

I don't want to use another MTA except for when sending outbound to another host (have to go quickly - I hope you understand what I'm trying to say). And PTR records are important as some MTAs (many - mine included) reject email if there is a mismatch (since sadly spammers do that a lot). Plus I like having the PTR RR. I have a lot of fun with my DNS server! Sadly will have to have only one IP or at least a smaller block (if allowed by the ISP - currently have a /29 and for IPv6 a /60 although only the IPv4 block is statically assigned).

And my ISP does not restrict outbound 25 for accounts that ask for it (and are configured right). So there's that. My new one does not either (though I might want to check that once again).

[xexyl]

Well the whole point is home system should run their mail through a public facing mail system to avoid having PTR is. Let's Encrypt is fine (never tried it, poor support on NetBSD). Anyway self-sign certs are just used for the TLS setup between home and the mail hub (both I control) so not important. All outbound mail relays via the mail hub, never directly from home since ISPs block outbound port 25 on residential accounts to prevent spammers.

I don't want to use another MTA except for when sending outbound to another host (have to go quickly - I hope you understand what I'm trying to say). And PTR records are important as some MTAs (many - mine included) reject email if there is a mismatch (since sadly spammers do that a lot). Plus I like having the PTR RR. I have a lot of fun with my DNS server! Sadly will have to have only one IP or at least a smaller block (if allowed by the ISP - currently have a /29 and for IPv6 a /60 although only the IPv4 block is statically assigned).

And my ISP does not restrict outbound 25 for accounts that ask for it (and are configured right). So there's that. My new one does not either (though I might want to check that once again).

.. of course if what you have works for you that's also good. I just prefer having it 'correct' (if you understand me). It's a lot of fun for me too so it works out well. Plus I'd not want to have to figure out a new way.

Anyway I'm glad it works well for you and hopefully this issue is resolved soon! I just made a comment to get a better idea of what exactly has to be done here to resolve it.

Best wishes for a great day to you both!

[lcn2]

We are using a fairly recent postfix version 3.5.25, in case that matters.

I'm testing within my NetBSD VM which comes stock with 3.8.4 and an alternative package 3.9.1.

It seems that 3.8.4 is close enough to our 3.8.5, based on these Ubuntu postfix 3.2.5 notes and these Debian postfix 3.2.5 notes. So we suggest version 3.8.4 as an alternative to 3.8.5 (and not 3.9.1).

@lcn2 Are you using a fresh install of whatover_os?

We are using a fresh install and up to date release of AlmaLinux 9.5 if that matters.

In the config I'm working, I'm marking root elements like domain name, host, install paths with comments as what needs to change between TESTING and PRODUCTION when ready.

# PRODUCTION

#mydomain = ioccc.org

#postfix_dir = /etc/postfix



# TESTING

mydomain = snert.net

postfix_dir = /usr/pkg/etc/postfix

From that I'm trying to get the TLS to the relay host working. After I'll fine tune the other elements. TLS and DNS setup is always a pain; thankfully I had most of it done for home use with Sendmail.

Yes.

UPDATE 0

Corrected some typos in our comment.

[xexyl]

Yes, we are VERY AWARE that an address such as postmaster@spam-magnet.example.org required for those who "own" the spam-magnet.example.org domain. Perhaps we don't care enough to maintain it? 😏

Ah yes ... 'own' is right.

Something that Hugh Daniel and Landon Curt Noll said was that "unless you can edit your DNS zone file, you are just a domain renter not a domain owner".

I was more thinking how that you can lose it - sometimes it seems for dubious reasons.

Don't get me started on the ICANN for allowing Cyrillic characters in domain names ... or for not dealing with domain theft or other such things. The constant increasing the renewal price is also bloody annoying.

Yes, the IOCCC judges can vi ioccc.org.zone.

My DNS server is authoritative too.

BTW: vi ioccc.org.zone was how we managed to break the publishing "log jam" (as the expression goes) and publish the IOCCC27 winners on GitHub. The IOCCC was just one command away from publishing the IOCCC27 winners for multiple months before they were finally published near the end of 2020. We will decline to get into reasons why this was the case out of politeness and conservation for those involved. Nevertheless, much of the work and the cause for the relay of IOCCC28 has been motivated to NOT returning to such a situation in the future.

We already discussed it anyway and [they] told me too so I already know anyway.

And indeed the mkiocccentry toolkit (along with jparse, dbg and dyn_array) plus GitHub is working well it seems!

Speaking of jparse I am about to commit to it. Unfortunately I have to go so I can't commit the many fixes (like the issue of when the minimum timestamp changes it would break txzchk test code) in mkiocccentry today. I hope tomorrow to address the bug in a function I discovered today.

[xexyl]

Sure .. although it never bothers me much. Again except for having to deal with DNSSEC. I sometimes wonder if it's even worth it but since there are all those bloody stale keys that dnssec-revoke REFUSES to revoke I am stuck with it in that way too. Well I could disable it at the registrar but I'd rather not

"Back in the day" when folks such as the late Hugh Daniel was working and implementing practical and useful crypro (no, NOT the scam that is bitcoin, we mean cryptography and cryptology), the topic of applying cryptographic verification to DNS was being debated. Unfortunately, too many "perpetual standards conference attendees" (allegedly) got into the mix at weighted down DNSSEC in the "thing" (🚽💩💨 (allegedly)) that it is today.

We OBSERVE numerous pitfalls and problems with people using DNSSEC. And while we are aware of certain technical benefits of DNSSEC, we see little upside to implementing DNSSEC. If asked, we would suggest to someone who has NOT deployed DNSSEC to carefully and accurately weigh the "reward / hassle / threat / loss" that comes with DNSSEC.

TL;DR DNSSEC, like System V UNIX from AT&T, is another reason to "just press ==> n <==" 🤓 (in our opinion).

P.S. In the value metric space, where 4.2 > V 🤓, DNS > DNSSEC (in our opinion).

P.P.S. The letsencrypt project of the ISRG, where the setup to create a cert for an "HTTPS" service is free and well automated (once you set it up), was the completion of a project on which Hugh Daniel was a founding member and worked on before he died.

Fun fact: I finally got the old keys out of the system! At least mine. Now it's a matter of waiting for the DNS ecosystem to have it. Then I can check the verifies again. That'll be great. I haven't tried deleting those files but I guess it will be fine now.

It turns it was to do with the managed keys. I did not imagine that.

Still the fact that so many have run into problems and the fact that some entities have totally broken configs making it useless (and in fact making it so one has to disable verifying DNSSEC when it's there!) and the fact it's been so many years is a sign it's never going to be what the creators imagined it will be. The fact I got these stale keys gone though is a success and a relief.

As for adoption it seems to me like IPv6. Somehow no matter how full the allocated range is we manage. IPv6 is decades old and yet we still haven't fully migrated there - kind of like we haven't fully migrated to DNSSEC! It seems to me that we'll never get to this stage, especially DNSSEC (which until people actually do it right it's arguably more harmful) but even IPv6.

I made a crude joke about it that I'm not sharing here (for obvious reasons). It just popped into my head. But really this all reminds me of the fact that some of the worst things - inventions and things people have done or things that have happened - started out with 'the best of intentions'. It seems that DNSSEC is in the same boat. IPv6 not so: it's a good thing but due to messing with the allocation (and other things) we have managed to get by without it. It does seem better to get it fully integrated though. Besides that it's also fun as you can spell things out.

[xexyl]

...
As for adoption it seems to me like IPv6. Somehow no matter how full the allocated range is we manage. IPv6 is decades old and yet we still haven't fully migrated there - kind of like we haven't fully migrated to DNSSEC! It seems to me that we'll never get to this stage, especially DNSSEC (which until people actually do it right it's arguably more harmful) but even IPv6.
...

As for IPv6: part of one of my IPv6 addresses (and I will sadly lose it when I get FTTH in the next month or two) is:

---

bad:f00d:dead:d00d

---

And another one has c0de (as you'd expect).

So you can have a lot of fun with it. Yet for whatever reason it's not fully here even after all these years.

[lcn2]

As for IPv6: part of one of my IPv6 addresses (and I will sadly lose it when I get FTTH in the next month or two) is:

bad:f00d:dead:d00d

❓‼️❓

Can you not route that to your home?

We still have our class C IPv4 we can use, and by always purchasing at least some fixed routable IP addresses from our service provider, we can route what we want to our location.

[xexyl]

As for IPv6: part of one of my IPv6 addresses (and I will sadly lose it when I get FTTH in the next month or two) is:
bad:f00d:dead:d00d

❓‼️❓

Can you not route that to your home?

Well currently it is but I'll likely lose it (not sure if new provider provides any without paying for it).

We still have our class C IPv4 we can use, and by always purchasing at least some fixed routable IP addresses from our service provider, we can route what we want to our location.

Nice. I have a /29 from my provider. However the new provider is a bit more expensive. It might not be as big of a deal but you have to either have a device that will support multiple IPs (with other requirements) OR lease one. That combined with the price of a block is cost prohibitive. I managed to buy a device (same company but one model lower - but still sufficient) but that was a hefty price too. So at least for now I cannot have the /29. I can have the /32 which I require for home.

But now that you mention home. I used to have Hurricane Electric IPv6 addresses. If they still have that (if they even exist) I could do that if I wanted. But maybe not worth it. I guess I'll see.

Even if I had to pay upfront more it's still worth it. We'll be going from 30/5Mbps down/up to 350Mbps up/down. They offer higher rates but I think I'll do just fine on 350Mbps! The next one is 1.5 (they recently for the same price made it 1.5Gbps up from 1Gbps). It'll be quite nice.

Lately I have had to repeatedly turn off/on WiFi in order for connections to work. It's actually kind of like Microsoft Windows - only worse. Well at least I don't have to deal with that I guess!

[xexyl]

QUESTION

What exactly do you need done to resolve this issue entirely? About to start work on the other repo (after a useful update to jparse which will allow for more defence in depth in the mkiocccentry tool and the chkentry tool too).

Thanks!

[lcn2]

WHOOP.WHOOP

In the era of anything goes top level domains, ** WHOOP.WHOOP** is a sure fire winner. 🤓

[xexyl]

elf$ mail ****test@ioccc.org
Subject: I blow my nose at you...

... you english kaa-nig-ats.
.
EOT
elf$

Feb 18 15:36:55 mx sendmail[24695]: 51IKaqVI013378: to=<****test@ioccc.org>, ctladdr=<achowe@snert.com> (1000/100), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=34971, relay=mx-2.rightbox.com. [103.168.172.220], dsn=2.0.0, stat=Sent (Ok: queued as CEBBB2CC01DD)

Received and replied. 👍

What was the reply ? :-)

I won't say what popped into my head as it's not very nice.

[SirWumpus]

#97 (reply in thread)

Status

• Have managed to setup a point-to-point VPN from the NetBSD VM to the gateway for testing in order to simulate inbound mail handling. Not perfect simulation, but at least allows me to verify configuration to a degree.

[SirWumpus]

What was the reply ? :-)

Is there someone else up there that we can talk to? 🙂

[xexyl]

What was the reply ? :-)

Is there someone else up there that we can talk to? 🙂

Very funny!

It reminds me of 'going downstairs' in the MUD I'm part of - I'm a high god (highest level) and when gods and immortals would go 'downstairs' they were going to play a mortal character; and if those were 'going upstairs' they would be doing the opposite. I suppose that's a joke in contexts of deism/theism but if so I have no idea. It always amused me though.

Thanks for the reply! It was a useful laugh.

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.

[lcn2]

Our proposed DMARC record for ioccc.org would initially be as follows:

; DMARC
;
; For more information on DMARC, see:
;
;       https://dmarc.org/overview/
;       https://datatracker.ietf.org/doc/html/rfc7489
;       https://vamsoft.com/support/tools/dmarc-policy-validator
;
_dmarc          IN      TXT     "v=DMARC1;p=none;pct=100;rua=mailto:dmarc-rua-spam-not@ioccc.org;ruf=mailto:dmarc-ruf-spam-not@ioccc.org"

Comments and suggestions welcome.

[xexyl]

I do find it quite amusing though: although you do have the email in the RR your MTA requires the specific subject and how will the report know to do that?

We have our "ways" that we will not discuss here. :-)

So I guessed. :-)

Although you also have a different email so maybe that is saying something else.

:-)

:-) :-)

Your turn? :-)

[xexyl]

I do find it quite amusing though: although you do have the email in the RR your MTA requires the specific subject and how will the report know to do that?

We have our "ways" that we will not discuss here. :-)

So I guessed. :-)

Although you also have a different email so maybe that is saying something else.

:-)

:-) :-)

Your turn? :-)

Incidentally: your idea sounds like a good plan. Maybe one day I'll add DMARC - without the email address of course. And whilst at it I'll remove the old SPF RRs and just keep the TXT ones (annoying that some 'linters' - as we might call them .. or not since that's not what they're called but you know what I mean :-) - complain about it though .. but at least it's not an error. Even so the fact I have talked about broken DNS configs make me think I should at least fix it ... but so busy with IOCCC and so tired with ... rubbish sleep and other things .. that I won't bother for now - maybe will do it during the contest: but so many zones to fix[0]).

[0] Okay technically it's only 12 but still it's annoying to have to do when it shouldn't even be necessary! Oh well.

[xexyl]

Speaking of DNS: what is really annoying is during updates (dnf) the silly maintainers make the files owned by root which causes named to fail to start! Shouldn't touch the permissions of the files (running an update of bind and bind-chroot - plus others - which is what made me think of it).

[lcn2]

Speaking of DNS: what is really annoying is during updates (dnf) the silly maintainers make the files owned by root which causes named to fail to start! Shouldn't touch the permissions of the files (running an update of bind and bind-chroot - plus others - which is what made me think of it).

Try using a Makefile to set the proper ownership and permissions. That Makefile can also alert you to if a critical file is missing.

[xexyl]

Speaking of DNS: what is really annoying is during updates (dnf) the silly maintainers make the files owned by root which causes named to fail to start! Shouldn't touch the permissions of the files (running an update of bind and bind-chroot - plus others - which is what made me think of it).

Try using a Makefile to set the proper ownership and permissions. That Makefile can also alert you to if a critical file is missing.

Oh it's more that when the post install script runs it fails to start. I just have to use chown on the directory.

Thanks for the suggestion though! (I actually do have a Makefile there for key signing.)

[xexyl]

And as for DMARC. Apparently for gmail if you're sending a large volume of emails you now have to use DMARC.

I think I saw another domain but not sure. Perhaps hotmail? Fortunately neither really affect me.

@SirWumpus: does DMARC require you put in an email address that can (obviously) be spammed?

UPDATE 0

Okay I see it does not require it. Perhaps you should change yours too, @lcn2 ?

[xexyl]

And as for DMARC. Apparently for gmail if you're sending a large volume of emails you now have to use DMARC.

I think I saw another domain but not sure. Perhaps hotmail? Fortunately neither really affect me.

@SirWumpus: does DMARC require you put in an email address that can (obviously) be spammed?

UPDATE 0

Okay I see it does not require it. Perhaps you should change yours too, @lcn2 ?

One website says it is recommended (strongly). This is what is sent apparently:

• Your domain name
• Date range
• Number of messages attempted to send
• IP of servers sending emails
• DNS name of the sending server
• DKIM key information
• Whether or not messages passed or failed SPF and DKIM email authentication checks

I fail to see how this is important in an email .. seeing as how you can just look at the logs (for almost all if not all of it). So it seems to me it's not worth it and it's just more spam and more to worry about.

UPDATE 0

Okay and it seems it is google and Yahoo. But only if you send in bulk. I guess that's not necessary for the IOCCC. But even if it is it seems useless to provide an email since you can get that information from the logs in a way that's easier to parse - even more so with logwatch.

[xexyl]

@lcn2 I just sent you (to the judges email) my postfix config (nothing revealing other than my IPs but since you already have ssh access on the server and since I am changing providers soon it doesn't matter :-) ).

I gave some useful things you might or might not know.

I also want to correct something I said earlier (here). I had said you don't need to run postmap: it will do it by itself in time. That is of course not correct. What is correct is you don't have to do a postfix reload in order for it to get seen. I do always do it right after to speed it up but it's not required.

I made some important bug fixes in some of the mkiocccentry tools today and I hope to look at the chkentry enhancements tomorrow but I will be leaving shortly.

Good day (to you too @SirWumpus)!

[lcn2]

@lcn2 I just sent you (to the judges email) my postfix config (nothing revealing other than my IPs but since you already have ssh access on the server and since I am changing providers soon it doesn't matter :-) ).

We will review that email (you may see we still have 👀 on your comment) after we finish the infrastructure need to process registrations.

[xexyl]

@lcn2 I just sent you (to the judges email) my postfix config (nothing revealing other than my IPs but since you already have ssh access on the server and since I am changing providers soon it doesn't matter :-) ).

We will review that email (you may see we still have 👀 on your comment) after we finish the infrastructure need to process registrations.

No rush of course. I just did see the eyeballs only to see the comment only to now get the email.

Hope it's of help. Depending on what and which is easier you can say something here or there.

Best wishes on the infrastructure stuff! I'm going to take a break and then I hope to continue on chkentry. Though the util function we will need I will commit (to jparse of course as it's related to the util functions for FTS).

[lcn2]

See the updates to comment GH-discussioncomment-12257206.

[SirWumpus]

Side Saddle: This not at all important, but I thought you might get a chuckle from the SMTP Welcome message I have customised using BarricadeMX. Having longish (3+ lines) can throw off some spambots that script their connection session, such that everything is out of sequence.

Now I collected this info from my local VM over a point-to-point SSH tunnel with my MX. The stuff you can do with SSH is so cool.

elf$ telnet 10.1.0.1 25
Trying 10.1.0.1...
Connected to 10.1.0.1.
Escape character is '^]'.
220-mx.snert.org ACHTUNG! SMTP #633 11K6HU080230811800
220-ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!  DAS KOMPUTERMASCHINE
220-IST NICHT FUR DER GEFINGERPOKEN UND MITTENGRABEN!  ODERWISE IST
220-EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN
220-MIT SPITZENSPARKEN.  IST NICHT FUR GEWERKEN BEI DUMMKOPFEN.  DER
220-RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HANDER IN DAS
220 POCKETS MUSS.  ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.
help
214-2.0.0 ESMTP RFC 1985, 3207, 4954, 5321 supported commands:
214-2.0.0     AUTH    DATA    EHLO    ETRN    HELO    HELP
214-2.0.0     NOOP    MAIL    RCPT    RSET    QUIT    STARTTLS
214-2.0.0
214-2.0.0 ESMTP RFC 2821, 5321 not implemented:
214-2.0.0     EXPN    TURN    VRFY
214-2.0.0
214-2.0.0 Administration commands:
214-2.0.0     CONN    CACHE   INFO    KILL    LKEY    OPTN
214-2.0.0     STAT    VERB    XCLIENT
214-2.0.0
214 2.0.0 End
quit
221 2.0.0 mx.snert.org closing connection #247 11K6HU080230811800
Connection closed by foreign host.
elf$

[xexyl]

Side Saddle: This not at all important, but I thought you might get a chuckle from the SMTP Welcome message I have customised using BarricadeMX. Having longish (3+ lines) can throw off some spambots that script their connection session, such that everything is out of sequence.

Now I collected this info from my local VM over a point-to-point SSH tunnel with my MX. The stuff you can do with SSH is so cool.

elf$ telnet 10.1.0.1 25
Trying 10.1.0.1...
Connected to 10.1.0.1.
Escape character is '^]'.
220-mx.snert.org ACHTUNG! SMTP #633 11K6HU080230811800
220-ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!  DAS KOMPUTERMASCHINE
220-IST NICHT FUR DER GEFINGERPOKEN UND MITTENGRABEN!  ODERWISE IST
220-EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN
220-MIT SPITZENSPARKEN.  IST NICHT FUR GEWERKEN BEI DUMMKOPFEN.  DER
220-RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HANDER IN DAS
220 POCKETS MUSS.  ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.
help
214-2.0.0 ESMTP RFC 1985, 3207, 4954, 5321 supported commands:
214-2.0.0     AUTH    DATA    EHLO    ETRN    HELO    HELP
214-2.0.0     NOOP    MAIL    RCPT    RSET    QUIT    STARTTLS
214-2.0.0
214-2.0.0 ESMTP RFC 2821, 5321 not implemented:
214-2.0.0     EXPN    TURN    VRFY
214-2.0.0
214-2.0.0 Administration commands:
214-2.0.0     CONN    CACHE   INFO    KILL    LKEY    OPTN
214-2.0.0     STAT    VERB    XCLIENT
214-2.0.0
214 2.0.0 End
quit
221 2.0.0 mx.snert.org closing connection #247 11K6HU080230811800
Connection closed by foreign host.
elf$

That is NOT what I expected but it's EXTREMELY funny (ad odd too which is a bonus)! Thanks! I'll share my 404 message on my web server .. and 403 too. My MTA welcome message is nothing exciting.

[xexyl]

403:

You don't have permission to access the requested object. And come now. Do you really think you have permission to view everything here? And do you really think that all kinds of requests are allowed? Of course, as a iuser you are the source of all computer errors and despite the fact that in this case you're very possibly a snoop (or some feeble attempt at AI) I'll forgive you - especially if you telepathically send me an apology; I don't expect it but if you do I would be most willing to telepathically accept your apology. Otherwise only the server can accept your actions and in which case I'm afraid you still won't be able to access everything here (... and you would not be able to even if you do apologise).

404:

The requested URL was not found on this server.

If you typed the URL manually then you didn't type well, typed a non-existent file, or I could be playing with your head and/or changed things. The latter is quite possible too but I wouldn't assume if I were you (it makes an ass of you but not me ...or something like that). You might try checking your spelling and try again.

If you think this is a server error you're wrong; however, if you obstinately insist that this is a server error please telepathically tell me about it so I can look into it and fix the problem (or tell you that you were wrong after all). Okay, you don't really have to use telepathy but odds are I won't be fixing what isn't broken (and generally speaking a 404 doesn't imply a server problem although it could happen).

Otherwise you can try going to the main page and finding your way through until you reach your final destination (which theoretically could be back here depending on what you are looking for and what actually exists here).

...

Just some fun injected into the messages and yes some might call it 'crazy' or 'eccentric' or who knows what else but what I find it is both amusing and fun. :-)

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.

[SirWumpus]

@lcn2 You should have received an email with a tarball and status summary:

---

Included is my current work to date.

• The Basic configuration works as previous seen.

• Client IP / domain restriction added and working

• Sender (MAIL FROM) restrictions added and working

• Recipient (RCPT TO) restrictions to work in progress as I try and sort out eval. order and other options that influence recipient rejection

---

[lcn2]

As I understand the spec. given in the OP, the IOCCC submission server wants to reject by default and only allow local users/services, aliases users, UUID users - much like a firewall setup. It's easier to specify who is allowed as a recipient as it's a smaller set.

Correct, @SirWumpus

On the server, we have a very specific remote sender and local receiver requirement.

Email going to the server will come via a SASL link from an upstream email relay that will forward specific email to the server.

If email is already being relayed from the MX to the submission server, the MX should already handle all the public facing stuff, SPF, DKIM, DNS allow/deny lists, etc. and just relay mail to the submission server (as permitted by the client_checks).

Outgoing email, generated locally on the server, will be sent to IOCCC registrants with a "reply to" address that will go elsewhere (not to the server).

There are no "normal" users on the server. There is a very specific inbound email function. There is a very specific outbound email function.

And while one might normally consider using an RBL, in this case, the restrictions are much tighter than any RBL can make. There is only one specific external email sender who can send to one very specific internal email address, and that email goes through a very specific email relay.

Nevertheless, caution needs to be applied. Email can be "infinitely forged" (as the expression goes). So in par,t we're having to rely on the RBL, SPF, DKIM, etc. of the email relay to help prevent someone from forging an email that looks like it comes from the allowed sender to the allowed receiver.

As to the issue of being a relay, the requirement is that email from outside should never go elsewhere outside. Email must come only from a specific sender address to a local receiver address via an encrypted SASL channel from a trusted MX relay.

There are also firewalls in place that restrict access to port TCP 25 to that trusted MX relay.

It is very much a requirement that email coming into the server never go back out from the server. Externally generated email must only arrive to a specific internal email address and nowhere else.

[SirWumpus]

Email going to the server will come via a SASL link from an upstream email relay that will forward specific email to the server.

By "upstream" I assume you mean the ioccc.org MX will relay to the submission server. I assume the ioccc.org MX is already setup with all manner of anti-spam measures, since it has existed for a long time.

If email is already being relayed from the MX to the submission server, the MX should already handle all the public facing stuff, SPF, DKIM, DNS allow/deny lists, etc. and just relay mail to the submission server (as permitted by the client_checks).

Outgoing email, generated locally on the server, will be sent to IOCCC registrants with a "reply to" address that will go elsewhere (not to the server).

I assume by "sent" it will pass through an existing outbound mail hub (the MX doing outbound duty?) which in turn has all the SPF/DKIM stuff handled and so avoid any need to update those controls for the submission server.

---

And while one might normally consider using an RBL, in this case, the restrictions are much tighter than any RBL can make. There is only one specific external email sender who can send to one very specific internal email address, and that email goes through a very specific email relay.

This para. arrived in an edit which appears to confirm my understanding. Thanks.

[xexyl]

As to the issue of being a relay, the requirement is that email from outside should never go elsewhere outside. Email must come only from a specific sender address to a local receiver address via an encrypted SASL channel from a trusted MX relay.

Which is why it would be good to include the parts I mentioned - even if nothing else.

There are also firewalls in place that restrict access to port TCP 25 to that trusted MX relay.

Of course!

It is very much a requirement that email coming into the server never go back out from the server. Externally generated email must only arrive to a specific internal email address and nowhere else.

Of course I did actually refer to your tighter restrictions (I think yesterday). Defence in depth is always good though. As for RBLs I can see your point - and if it works well there's no need to use one. I personally find them very useful but I also don't have severe limitations on what I can receive. I mean I have restrictions of course (including (A|AAAA) <-> PTR look-ups) but I don't require a certain subject for example.

Whatever the case I'm sure you'll work it out fine.

I was distracted with Tolkien stuff (who would have thought that ? :-) ) but now I hope to get to the IOCCC again. First want to briefly bring up something about chkentry 'over there' though.

[lcn2]

Email going to the server will come via a SASL link from an upstream email relay that will forward specific email to the server.

By "upstream" I assume you mean the ioccc.org MX will relay to the submission server. I assume the ioccc.org MX is already setup with all manner of anti-spam measures, since it has existed for a long time.

If email is already being relayed from the MX to the submission server, the MX should already handle all the public facing stuff, SPF, DKIM, DNS allow/deny lists, etc. and just relay mail to the submission server (as permitted by the client_checks).

Outgoing email, generated locally on the server, will be sent to IOCCC registrants with a "reply to" address that will go elsewhere (not to the server).

I assume by "sent" it will pass through an existing outbound mail hub (the MX doing outbound duty?) which in turn has all the SPF/DKIM stuff handled and so avoid any need to update those controls for the submission server.

And while one might normally consider using an RBL, in this case, the restrictions are much tighter than any RBL can make. There is only one specific external email sender who can send to one very specific internal email address, and that email goes through a very specific email relay.

This para. arrived in an edit which appears to confirm my understanding. Thanks.

Correct on your 3 points, @SirWumpus.

BTW

The allowed sender will send email to the MX service (that as all the RBL, SPF, DKIM, etc. stuff) because the MX for the allowed target address will be the MX service. So, from the allowed sender's perspective, they are simply sending email to the MX service for @example.org.

What we will have to setup on the MX service (somehow), is a mail rule that will forward email from the allowed sender to the allowed target address on the server. The postfix configuration on the server needs to permit that and only that function. I.e., the postfix configuration needs to restrict the client to be the MX service, restrict the SMTP FROM to the allowed sender, and the SMTP TO target address on the server.

How the MX service will forward that email is TBD. We know that we could create a MX for the server, and then configure the MX service to forward email to allowed_address@server.example.org. However, we would rather NOT have to add a special MX for the server because that will "paint a spam target" (as the expression goes) on the server. It would be better if we can do that without a server MX, however we suspect that won't be allowed by the MX service (perhaps in part because of all of their RBL, SPF, DKIM, etc. stuff). We doubt MX service would allow the forwarding of email to allowed_address@ip.ad.dr.ress, especially without an MX record.

Yes, we do NOT have "raw" access to the MX service configuration. We are limited to the account interface that the MX service provides. That is OK, because the MX service is excellent, has years of experience and keeps up with the best practices of email. We know that the account interface of MX service provides will allow us to forward email from the allowed sender to a new allowed_address@server.example.org IF there is an MX record for the server.example.org host.

[xexyl]

First of all I must amend what I had said. Whatever source I saw that ZEN spamhaus is not operating is wrong. It is operating and it's the combined RBLs. I just reinstated it in my config. I realise you might not need to use RBLs but I wanted to clarify that just because.

BTW

The allowed sender will send email to the MX service (that as all the RBL, SPF, DKIM, etc. stuff) because the MX for the allowed target address will be the MX service. So, from the allowed sender's perspective, they are simply sending email to the MX service for @example.org.

What we will have to setup on the MX service (somehow), is a mail rule that will forward email from the allowed sender to the allowed target address on the server. The postfix configuration on the server needs to permit that and only that function. I.e., the postfix configuration needs to restrict the client to be the MX service, restrict the SMTP FROM to the allowed sender, and the SMTP TO target address on the server.

How the MX service will forward that email is TBD. We know that we could create a MX for the server, and then configure the MX service to forward email to allowed_address@server.example.org. However, we would rather NOT have to add a special MX for the server because that will "paint a spam target" (as the expression goes) on the server. It would be better if we can do that without a server MX, however we suspect that won't be allowed by the MX service (perhaps in part because of all of their RBL, SPF, DKIM, etc. stuff). We doubt MX service would allow the forwarding of email to allowed_address@ip.ad.dr.ress, especially without an MX record.

Yes, we do NOT have "raw" access to the MX service configuration. We are limited to the account interface that the MX service provides. That is OK, because the MX service is excellent, has years of experience and keeps up with the best practices of email. We know that the account interface of MX service provides will allow us to forward email from the allowed sender to a new allowed_address@server.example.org IF there is an MX record for the server.example.org host.

So the only thing that has to be worked out is the thing that you say is TBD?

Well anyway you asked me to look at the rules and guidelines again. I'm going to try and get that done today.

Best wishes on the final tasks on your end!

[lcn2]

This is still an important infrastructure issue: perhaps it can be solved before IOCCC29 opens?

[xexyl]

This is still an important infrastructure issue: perhaps it can be solved before IOCCC29 opens?

Did you look at my email with my config ?

[lcn2]

We came up with a Postfix solution that included a fair amount of code that interfaces with Postfix, including a test suite.

The fix involved some adjustments in our email service provider, a minor DNS change, and a fair amount of code needed to validate inbound email messages. Our changes include things such as firewalls (yes more than 1), SELinux rules, IP address validation, SMTP envelope validation, email header validation (including some cryptographic stuff), as well as message body validation.

We apologize that we cannot go into greater detail in this public forum: rest assured that we are following best practices, and that the postfix configuration has undergone extensive 3rd party review.

The system has tested well, and is expected to go live well in time for *IOCCC30 to go into pending state.

Thanks to @SirWumpus and @xexyl for your efforts and ideas.

[xexyl]

We came up with a Postfix solution that included a fair amount of code that interfaces with Postfix, including a test suite.

The fix involved some adjustments in our email service provider, a minor DNS change, and a fair amount of code needed to validate inbound email messages. Our changes include things such as firewalls (yes more than 1), SELinux rules, IP address validation, SMTP envelope validation, email header validation (including some cryptographic stuff), as well as message body validation.

We apologize that we cannot go into greater detail in this public forum: rest assured that we are following best practices, and that the postfix configuration has undergone extensive 3rd party review.

The system has tested well, and is expected to go live well in time for *IOCCC30 to go into pending state.

Thanks to @SirWumpus and @xexyl for your efforts and ideas.

Glad to have been able to help. That's great it'll be ready for IOCCC30! I don't know if in the end you used my postfix config but I hope it was useful anyway.

Best wishes on a good day.