[BlueOnyx:26522] Re: Postfix: Allow relay access by IP (and hostname)
Hi Michael! I missed this email last night, but apparently this morning at 6am when the RPMs came in, it started working, automagically. I know this because the backlog of outgoing emails from things that hadn't been working then triggered rate alerts from my upstream provider. In the intervening time when emails weren't getting relayed, apparently the attempts and retries, etc. had accumulated in the database and there were upwards of 100,000 emails that would have been headed outbound. That made me look for emails about the fix, and there it was. I then frantically started trying to STOP 100K emails from getting delivered. I'm assuming, from the implementation and what I found in the mynetworks entry, it will take pretty much anything listed in the Relay field from the UI and put it directly in. That would allow the use of a CIDR netmask to be part of the entry and then be passed directly into the Postfix config in that same manner. I've not been able to test that yet, but now that I've sorted the backlog, I'll start playing more with the relaying functionality. Very much appreciate the fix, and hope others find it useful as well! Thanks! -- Chad On 9/25/2023 8:59 PM, Michael Stauber wrote: Hi Chad, Your original recommendation was: "Change your "mynetworks" line in /etc/postfix/main.cf to something like this if you want to allow the whole 192.168.0.0/16 network to be able to relay through it: mynetworks = 127.0.0.0/8 [::1]/128 192.168.0.0/16 I did this, but find that, when I execute the postfix restart, them main.cf gets rewritten, and mynetworks is updated to: I just published base-email-* RPMs for BlueOnyx 5210R and 5211R which fix this issue. When you now restart Postfix, the "mynetworks" line in /etc/postfix/main.cf will be rewritten to include the following: - Localhost IPv4 - Localhost IPv6 - All IP addresses bound to your server - All IPs and Hostnames from "Server Management" / "Network Services" / "Email", "Advanced"-tab, field "Relay Email From Hosts/Domains/IP Addresses" So anything you specify under "Server Management" / "Network Services" / "Email" / "Advanced"-tab, field "Relay Email From Hosts/Domains/IP Addresses" will be allowed to relay through your server without authentication. That turns your Postfix into an open relay for the specified hosts or IPs. Preferably you should *not* use Hostnames in that field, but only IPs. But if need be, hostnames (of the sending servers) will also work, yet these could be spoofed by someone who knows you allow that hostname to relay. ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26496] Re: The Postfix learning curve continues
Thanks for the explanation, Michael.
Most of the challenges are, honestly, coming from other solutions that
send telemetry, etc. both to local admin (i.e. me) and for remote
diagnostics/statistics. The emails that are going to domains hosted by
my BlueOnyx, as you'd expect, get delivered just fine. It's those pesky
outgoing things (and to be honest, I also use internal email to external
SMS notification emails for some things that also get shot down).
While none of these are life and death critical, I'm glad to know that
at least the problem is understood, and appreciate the complexities of
implementing a fix. Hopefully parsing the IF{postfix} then {ensure IP's
only} won't be a big lift, and also won't disrupt anything else that
needs to work. I respect that my challenge may be a specific to me one,
and that doing something about it may not be practical without breaking
other things. If that ends up the case, just tell me. :)
Thank you sir!
-Chad
On 9/21/2023 1:39 AM, :
The complication is that the GUI field "Relay Email From
Hosts/Domains/IP Addresses" accepts both IPs and domain names, but the
"mynetworks" line in Postfix just accepts IPs. So I'll have to throw in
some extra cogs and wheels to make sure that only IPs end up in the
"mynetworks" line. But this is doable.
I'll play around with it tomorrow and will see if I can work this out
and then we'll have a YUM update ready to fix this in the next few days.
-- With best regards Michael Stauber
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26492] Re: The Postfix learning curve continues
Hi Michael. I'm resurfacing an issue from about a month ago, on my transition to Postfix. I've simply not had the time to worry about my internal stuff not working, until now. Your original recommendation was: "Change your "mynetworks" line in /etc/postfix/main.cf to something like this if you want to allow the whole 192.168.0.0/16 network to be able to relay through it: mynetworks = 127.0.0.0/8 [::1]/128 192.168.0.0/16 Then restart Postfix and see if that helps: systemctl restart postfix" I did this, but find that, when I execute the postfix restart, them main.cf gets rewritten, and mynetworks is updated to: mynetworks = 127.0.0.0/8 127.0.0.1/32 [::1]/128 192.168.0.212/32 192.168.0.213/32 192.168.0.214/32 the 192*/32 address correlate to the vSites that I have configured. I'm not sure how I can prevent this from getting overwritten, as when I did add the 192.168.0.0/16, it was removed, and replaced as I showed above. Hoping to get this all working, now that I have a bit more time to dedicate to it. Thanks! -- Chad ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26382] Re: The Postfix learning curve continues
Hello Michael. Appreciate the continued assistance. The relay error comes in this section: Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: generic_checks: name=permit_mynetworks status=0 Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: generic_checks: name=reject_unauth_destination Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: reject_unauth_destination: emailal...@domain.com Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: permit_auth_destination: emailal...@domain.com Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: ctable_locate: leave existing entry key c...@bersche.com?emailal...@domain.com Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: NOQUEUE: reject: RCPT from backup.bersche.com[172.18.172.106]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: generic_checks: name=reject_unauth_destination status=2 Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: >>> END Recipient address RESTRICTIONS <<< Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: > backup.bersche.com[172.18.172.106]: 554 5.7.1 : Relay access denied Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: watchdog_pat: 0x558e6487faa0 Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: vstream_fflush_some: fd 10 flush 53 Jul 31 14:36:33 mail postfix/submission/smtpd[645290]: smtp_get: EOF From what I can tell the forward and reverse DNS entries are fine, and I'd received no bounces from prior to conversion to Postfix. I did search for all other relay issues, and there are three email addresses being denied, with identical issues. I'm glad to provide you logs from before Postfix and after, if that's helpful. I just didn't want to flood the list with a bunch of attachments Thanks! ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26379] Re: The Postfix learning curve continues
Hi Michael. I'd tried setting the relay configuration previously, and it seems to not be honored for some reason. I went with the widest scope of my network to start with, and also explicitly listed hostnames and IP address of a specific system. I set the following via the GUI, which set /etc/postfix/access to show: # cat access photos.bersche.com RELAY 172.18.170.206 RELAY 172.18 RELAY bersche.com RELAY After this, I connected via telnet from a server to Blueonyx port 25: $ telnet mail.bersche.com 25 Trying 172.18.170.213... Connected to mail.bersche.com. Escape character is '^]'. 220 mail ESMTP Postfix ehlo photos.bersche.com 250-mail 250-PIPELINING 250-SIZE 10240 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING mail from: 250 2.1.0 Ok rcpt to: 250 2.1.5 Ok rcpt to: 554 5.7.1 : Relay access denied When I try the same by connecting from my BlueOnyx server itself: # telnet mail.bersche.com 25 Trying 172.18.170.212... Connected to mail.bersche.com. Escape character is '^]'. 220 mail ESMTP Postfix ehlo mail.bersche.com 250-mail 250-PIPELINING 250-SIZE 10240 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING mail from: 250 2.1.0 Ok rcpt to: 250 2.1.5 Ok rcpt to: 250 2.1.5 Ok I looked into the Postfix configuration, which seems to list the hashed access file: # postconf -p | grep -i access access_map_defer_code = 450 access_map_reject_code = 554 parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps postscreen_access_list = permit_mynetworks smtpd_log_access_permit_actions = smtpd_null_access_lookup_key = <> smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/suspended_vsites, check_recipient_access hash:/etc/postfix/suspended_vsites, check_sender_access hash:/etc/postfix/suspended_users, check_recipient_access hash:/etc/postfix/suspended_users, permit_sasl_authenticated,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unknown_sender_domain,reject_unknown_recipient_domain,permit_mynetworks,reject_unauth_destination,reject_unauth_pipelining,reject_invalid_hostname,reject_non_fqdn_hostname,check_sender_access hash:/etc/postfix/access,permit smtpd_sender_restrictions = permit_mynetworks, reject_unknown_sender_domain, check_sender_access hash:/etc/postfix/access Should I start playing around with mynetworks entries next? I feel like I'm just missing something obvious here ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26377] Re: The Postfix learning curve continues
Hi Larry. I did find the mynetworks parameter. In my main.cf it's set as: mynetworks = 127.0.0.0/8 127.0.0.1/32 [::1]/128 172.18.170.212/32 172.18.170.213/32 172.18.170.214/32 From what I can tell, these represent the vsite addresses that I have configured and was automatically created. I thought about adding overriding this via /usr/sausalito/bin/custom-postfix-confgen.sh but prior to doing that, I figured I'd inquire if that's the best route, as if I modify any vsites, etc., then I'd have to manually maintain the config going forward. In the meantime, I'll go do some override of the mynetworks and see if that changes any behaviors. On 7/30/2023 9:21 AM, Larry Smith wrote: Chad, You mention "devices in my network" but it appears you have not set your "mynetworks" parameter to include these addresses. If you set the mynetworks to the entire network (your private net such as 172.18.0.0/16 or appropriate) then the permit_mynetworks would allow relay from these devices I think. ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26375] The Postfix learning curve continues
As I wrote to the list earlier, I've recently switched over to Postfix mainly to allow for external authorized outbound email to be sent, and I'm finding a few things along the way that aren't working as they had. I'm now facing an issue that I'm not sure how to address in Postfix. I have a number of devices in my network (BMC/ILO/iDRAC) and other consumer devices (like NAS systems, etc.) that typically send emails when health/status issues arise. Unfortunately, the majority of these do not have any concept of authentication to the email server before they try to send email. Some of these notices are sent to email addresses that are hosted on my BlueOnyx system, but some of them also get sent to other (remote) monitoring email addresses. I explicitly listed the device IP addresses in the relay field, but, obviously that's not working since the authentication isn't taking place. Maillog shows things similar to: Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: generic_checks: name=permit_mynetworks status=0 Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: generic_checks: name=reject_unauth_destination Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: reject_unauth_destination: emailal...@external.com Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: permit_auth_destination: emailal...@external.com Jul 29 21:49:32 mail postfix/submission/smtpd[427630]: NOQUEUE: reject: RCPT from backup-server.bersche.com[172.18.172.106]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: generic_checks: name=reject_unauth_destination status=2 Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: >>> END Recipient address RESTRICTIONS <<< Jul 29 22:02:30 mail postfix/submission/smtpd[429547]: > backup-server.bersche.com[172.18.172.106]: 554 5.7.1 : Relay access denied Given that I can't update the devices to support authenticated email, is there a path forward to allow certain known unauthenticated email sessions to proceed? I'd not anticipated this in the update, but found that I'd not been getting alerts/updates that I had been before the migration and started digging. Thanks for all the help. My experience with Postfix is much less than Sendmail, and I'm trying to adapt. ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26368] Duplication of email delivery based on /etc/mail/aliases
Since my switch to Postfix, just a few days ago, I've noticed that, for some odd reason, I'm now getting two emails, rather than one based on entries in my aliases file. My /etc/mail/aliases contains the following line: bjb: bjb, chadb I have a dedicated account for my elderly mother where she gets her ebills sent to. To make sure none are missed, I send a copy also to my own account, with her knowledge. This had been working flawlessly using Sendmail: each account would get a (single) copy of each email sent to that account. I switched to Postfix earlier this week, and since then, I get two emails delivered to the chadb account, but still only a single one to the bjb account. I suspect this has something to do with the different way that Postfix handles determining if there are duplicates in a delivery vs Sendmail, but I'm at a bit of a loss to figure out if there's any way for me to stop this from happening. It's not a huge deal, but it's making duplicates that aren't needed. Any mitigation suggestions are much appreciated! -- Chad ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
[BlueOnyx:26367] ISP Email relay changes, and my 18 hour journey to a solution
First, I'm going to publicly thank the ongoing efforts of Michael and everyone associated with keeping BlueOnyx alive and the awesome community it is. My journey with BlueOnyx started when I was working at Sun, and they handed out a bunch of the Cobalt Qube's to engineers. The design and management was really just what I wanted for my home, and I jumped in fully, getting my own domain, running my own email server, etc., etc. Fast forward to now 20+ years later, and still with the same ISP (Charter -> Spectrum). I'd been happily using their SMTP relay with no issues for all that time. Pointed Sendmail at it as a smart relay and things just worked. Until yesterday, when Spectrum finally tracked down the last open relay from the legacy RoadRunner / TWC portion of their network, and no longer allowed it to forward emails. I'd paid attention to the thread in late May, where Michael outlined how to configure Postfix for authenticated email relay. I kept those messages in my local archive of "this may come in handy" postings. So when emails started failing to deliver yesterday afternoon, I first panicked, and then set about the task of find a way to get things working again. Keep in mind, I run email for my household of 4. My first attempt was simply to configure Postfix, set up the authentication per the steps that Michael had so accurately outlined and figured I'd be done in time for a late dinner. That was not to be the case. Emails wouldn't deliver, and debugging the process wasn't terribly straightforward, as the failure reason wasn't making it into the logs. So I set up an instance of Thunderbird to mimic the process, and turned on debugging there. This showed that Spectrum would accept my authentication, but would only accept emails with a FROM address that matched the authentication used. Well, that's not going to work... I figured trying to reason with Spectrum was going to be an effort in futility, so I started looking for other alternatives. Now, it should be pointed out that I'm not the only person that's facing a similar problem. I found a thread on Spectrum's own discussion community where several others were facing the exact same problem, and weren't happy about the total apathy that Spectrum was showing. I contemplated for a brief moment if their Business solution would make any of this easier, but I didn't really want to rely on that, so I dove into looking for email relay services. I found many, but narrowed it down to three: smtp2go.com, mailtrap.io, and dnsexit.com. Based on longevity, website information, and implementation guides available, I decided I'd start with smpt2go and see how painful the process would be, but I needed 6 hours of sleep first. This morning, I signed up, and put in the mandatory entries in my DNS records...and waiteduntil it finally propagated far enough that smtp2go would let me proceed. I then created a domain userid/password, and added it to the sasl_passwd file, and updated my relay host, following the steps Michael had already posted. This process was absolutely simple! Having done that, outbound email was once again happy (inbound was NEVER impacted!), as evidenced by my ability to now post this to the list. The only odd things that I've currently noticed, I believe, are part of the switch to Postfix from Sendmail (yes, long overdue but if it ain't broke, don't fix it!). My hostname, for some reason, changed from mail.foo.bar to just mail. No idea why. Doesn't seem to impact anything, yet. I'm hoping it won't wreak havoc on any of my Let'sEncrypt certificates, etc. The other oddity is that I had an entry in /etc/aliases to send a copy of emails that came in to a specific inbox to two recipients. For some reason, I'm now getting TWO copies of those emails, but the other user is only getting a single copy. If I can sort out these two issues, I'll be thrilled, but they don't seem to be hugely impacting, yet. The fix wasn't hugely difficult, just time consuming. Hopefully this will continue to work, and not having the dependency on my ISP is, honestly, a relief. I get the security side of things, and why Spectrum changed their relays (they weren't completely open before, as if you weren't part of their network block they'd not let you relay), but the lack of notice and a reasonable way of being able to allow access for those that need it was frustrating. Thanks for reading, and hope maybe there's a tidbit in here for someone. -- Chad ___ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
