Re: Using Postfix sendmail without having Postfix daemon running all the time?
YMMW, but I solved this using ssmtp to replace sendmail. According to Arch it may be poor choice, since it is not maintained https://wiki.archlinux.org/index.php/SSMTP Just my 2 cents Thu, 6 Aug 2020 09:44:24 +0300 skrev Otto Kekäläinen : > Hello! > > Is it possible to send email using the Postfix provided > /usr/sbin/sendmail command on a system where Postfix is installed, but > not running permanently as a service? > > > Background: > > I have a resource constrained system where I want to avoid running > excess processes, and it rarely sends email. When it sends, it just > relays to a proper Postfix host accessible on the local network. There > is no incoming nor local mail delivery needs on that system. > > I have been using msmtp for this need, but its handling of multiple > recipients in the same mail is too simple and I'd rather use Postfix > that parses and validates recipients properly. > > In my testing the command sendmail on a system where Postfix is > installed does accept the email but it puts it in a local queue > (verified by mailq) and then the queue just sits still and no mail is > delivered. Manually running postflush complains that Postfix is not > running. If I quickly cycle 'postfix start' and 'postfix stop' the > service starts and sends out the queue and everything works, but > ideally I'd like an invocation of /usr/sbin/sendmail to immediately > send off the email to the relay host and not depend on a permanently > running Postfix daemon. Is this possible? > > I've tested the -G and -q options mentioned at > http://www.postfix.org/sendmail.1.html but they don't seem to do this > what I was looking for.
Re: TLS Settings and Mobile Clients
On 05 Aug 2020, at 16:08, Asai wrote: > The main question is just what will break if we allow TLS only. Software more than a decade old that is unsupported. TLSv1.0 and 1.1 should no longer be used for anything but opportunistic unvalidated encryption on port 25, no non TLS should be used under any circumstances. -- I WILL NOT CALL MY TEACHER "HOT CAKES" Bart chalkboard Ep. 7G10
Re: TLS Settings and Mobile Clients
On Mon, Aug 03, 2020 at 03:25:22PM -0700, Asai wrote: > In trying to upstep our general security, we're trying to implement some > of the recommendations on this list: > https://access.redhat.com/articles/1468593 > > It seems like the bulk of this is in raising the encryption on SMTP > delivery. You should be more explicit about whether you're asking about incoming mail or outgoing mail. But you mentioned iOS clients, I will assume you're only asking about inbound submission. > One question I have is, if we implement some of these settings like, > tls_auth_only, or tls_mandatory_protocls to exclude SSLv2 and SSLv3 will > this break iOS (or any other) mobile operability? - Yes, SASL auth should only be offered via STARTLS and only port 587 (and if applicable also 465). - Yes, clients that were misconfigured to not use TLS might then not be able to submit email, but they need to be configured correctly, rather than neglected. - Yes, on the *submission* ports serving mail clients, you SHOULD disable all TLS versions older than TLSv1.2. This may break some rather dated versions of Outlook. These should be upgraded, rather than neglected. I would not expect any issues with iOS. > Or, does anyone have any better general guidelines for hardening Postfix? Be judicious, excessive hardening is often counterproductive. The documentation and default settings are your best guides, more so that something some guy said on the Internet. On Thu, Aug 06, 2020 at 01:14:35AM +0200, Benny Pedersen wrote: > > Thanks for your reply. We are already doing that. The main question > > is just what will break if we allow TLS only. Do you have any > > experience with this? > > nothing will break if TLSv1.1 is disabled, so end result is to not > support SSLv2, SSLv3, TLSv1.1, all enabled is then TLSv1 and TLSv1.2 This is true inbound, but NOT true outbound, when you disable SSLv2, SSLv3 and TLSv1.1, *all* you're left with is TLSv1. The TLS client (Postfix outbound SMTP delivery agent) protocol range needs to be contiguous. DO NOT "punch holes" in the protocol list. Do NOT disable TLSv1.1 (even though largely unused, it does no harm, and is not worse than TLSv1) unless you also disable all the older versions, leaving only TLSv1.2 (and TLSv1.3 if your OpenSSL runtime is new enough). -- Viktor.
Re: TLS Settings and Mobile Clients
On 06 Aug 2020, at 02:09, Viktor Dukhovni wrote: > - Yes, on the *submission* ports serving mail clients, you SHOULD > disable all TLS versions older than TLSv1.2. This may break > some rather dated versions of Outlook. These should be upgraded, > rather than neglected. I would not expect any issues with iOS. It may ne possible that a very old device running something like iOS 4 or maybe 5 does not support TLS1.2, but it is very unlikely anyone is using a device that old, and they are not able to check mail with most providers. (I know for certain that iOS 8 supported TLSv1.2, but I am unsure what version of iOS added support for it, I would guess it was around iOS 6. TLSv1.3 was added in iOS 11.) -- There used to be such simple directions, back in the days before they invented parallel universes - Up and Down, Right and Left, Backward and Forward, Past and Future... But normal directions don't work in the multiverse, which has far too many dimensions for anyone to find their way. So new ones have to be invented so that the way can be found. Like: East of the Sun, West of the Moon Or: Behind the North Wind. Or: At the Back of Beyond. Or: There and Back Again. Or: Beyond the Fields We Know. --Lords and Ladies
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On 2020-08-06 Otto Kekäläinen wrote: > Is it possible to send email using the Postfix provided > /usr/sbin/sendmail command on a system where Postfix is installed, > but not running permanently as a service? You could wrap the command in a script that starts and stops the Postfix service when invoked. #!/bin/bash sudo service postfix start sendmail ... sudo service postfix stop However, I wouldn't recommend doing that since you'd have to manage concurrency, handle errors and other fun things. Postfix isn't that heavy on system resources. Just configure it as a null client [0] that sends to your upstream Postfix and leave it running in the background. Alternatively use something like mailx [1] to send directly through the upstream server: echo "message" | mailx -S smtp=smtp://mail.example.com ... [0]: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client [1]: https://www.systutorials.com/sending-email-using-mailx-in-linux-through-internal-smtp/ Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: Forwarding best practices
Dnia 5.08.2020 o godz. 14:23:00 Bob Proulx pisze: > > The Best Practice for forwarding today is not to do it. It has long > been a friendly allowed practice on the net. But as Yahoo, Google, > Microsoft, others, become the 800lb gorillas driving things then > nothing is traditional or standard anymore. Now it is the rule of > might makes right. And they are the ones with the might. [...] > But of course I assume that your site has been allowing forwarding for > a long time. It's now part of the status quo there. Changing that > would be very disruptive. I understand that completely. It's a > problem. A problem without any good solutions. I can only suggest > that you be aware that it is "thin ice" and keep looking for a > solution. Along with the rest of us. What's ironic in all this mess is that Gmail itself gives the users option to forward mail to a different address... -- 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: Forwarding best practices
On 06 Aug 2020, at 04:32, Jaroslaw Rafa wrote: > Dnia 5.08.2020 o godz. 14:23:00 Bob Proulx pisze: >> >> The Best Practice for forwarding today is not to do it. It has long >> been a friendly allowed practice on the net. But as Yahoo, Google, >> Microsoft, others, become the 800lb gorillas driving things then >> nothing is traditional or standard anymore. Now it is the rule of >> might makes right. And they are the ones with the might. > [...] >> But of course I assume that your site has been allowing forwarding for >> a long time. It's now part of the status quo there. Changing that >> would be very disruptive. I understand that completely. It's a >> problem. A problem without any good solutions. I can only suggest >> that you be aware that it is "thin ice" and keep looking for a >> solution. Along with the rest of us. > > What's ironic in all this mess is that Gmail itself gives the users option > to forward mail to a different address... Doubly ironic since gmail is one of the worst services for ACCEPTING forwarded mail. -- "Are you pondering what I'm pondering?" "I think so, Brain. But would the villains really have gotten away with it, if it weren't for those pesky kids and their dog?"
Re: Forwarding best practices
Bob Proulx wrote: No matter what you do on your end there is no way to guarentee that the large mailbox providers will accept the forwarded messages. FTFY. :( Because at any point in time any of those users might click "Spam" on the message. And there is no way you can prevent this. It's a human problem of human training. It's not even about forwarded mail, or spam. I'm plugged in to Microsoft's "Junk Mail Reporting Program" for mail coming from both our outbound cluster and forwarded from our MX cluster. End users on Hotmail/Outlook.com routinely mark *legitimate direct messages in ongoing conversations* as spam. They report *legitimate government communications about something they've asked a government office about*. They flag *mail from their lawyer*. I can only guess that the "Mark as spam" button looks a lot like a "Delete" symbol of some kind, or I have to give up all hope of intelligence on the part of end users. My experience is that if it is Microsoft that they will allow one free black eye for you. I contact them and say, hey, what's the data for this so I can improve things? What message do you have in the corpus of evidence for me? I want to figure out what is happening and stop it. They write me back and say, "Don't talk to me you spammer. We will show you nothing. But we will delist you this one time." Obviously this is a paraphrase from memory. Now delisted things work okay again for a while. Then for reasons I have no idea there suddenly Microsoft rejects all mail again. I try the official contact channels. Now they go, "Don't talk to me you spammer, you are a repeat offender, we are not going to show you anything, and we are not talking to you again." Paraphrasing again. Or they refer you to their rules for "bulk senders", which are variously inapplicable or utterly irrelevant for both forwarded mail and ISP-type outbound relay mail flow. I have yet to see any evidence from Microsoft as to what messages they think are worthy of being IP blocked regardless of my attempts to communicate with them. If you can get recognized as a suitable contact for your outbound IPs with Microsoft's SNDS and JMRP you can start seeing (some of?) the mail marked as spam. It's helped us locate low-volume compromised accounts now and then. If you get IP-blocked, you're sending/forwarding "too much spam" (whatever that means), and in the end it may just come down to telling your users they can't forward mail to Hotmail accounts any more as a matter of policy. Therefore I have no way to improve processes on my system. I am thinking one of my users is forwarding and then reporting messages as spam. But without data I can't be sure. Without data I have nothing to grip upon. I don't know anything firm about who or what. Eventually I am forced to route Microsoft destinations through a different IP address to avoid the IP block. They have the might and I do not. Sometimes it seems like they're blocking because it's a day ending in y. -kgd
Re: Forwarding best practices
On Thu, Aug 6, 2020, at 09:53, Kris Deugau wrote: > > I can only guess that the "Mark as spam" button looks a lot like a > "Delete" symbol of some kind, or I have to give up all hope of > intelligence on the part of end users. In many of the email programs I use, J/K are the "next message/previous message" keyboard shortcuts. In Outlook, J is the "Mark as Junk" shortcut. I swear I hit it about once a day as I'm switching email clients ... -- Harald Koch c...@pobox.com
Re: Forwarding best practices
The Best Practice for forwarding today is not to do it. It has long been a friendly allowed practice on the net. But as Yahoo, Google, Microsoft, others, become the 800lb gorillas driving things then nothing is traditional or standard anymore. Now it is the rule of might makes right. And they are the ones with the might. Ummm NOT forwarding translates to vendor lock-in. IMO, the best practice for forwarding, today, is to offer an email-address-for-life, the way many alumni & professional associations do. Then again, I'm a firm believer in managing my own domains, and not putting myself in the position where a vendor can lock me in. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On Thu, Aug 06, 2020 at 09:44:24AM +0300, Otto Kekäläinen wrote: > Is it possible to send email using the Postfix provided > /usr/sbin/sendmail command on a system where Postfix is installed, but > not running permanently as a service? Sure, the sendmail command will just deposit the mail into the maildrop queue. > I have a resource constrained system where I want to avoid running > excess processes, and it rarely sends email. When it sends, it just > relays to a proper Postfix host accessible on the local network. There > is no incoming nor local mail delivery needs on that system. What do you mean with "resource constrained"? An idle postfix starts master, qmgr and tlsproxy. There are not much resources involved. > I have been using msmtp for this need, but its handling of multiple > recipients in the same mail is too simple and I'd rather use Postfix > that parses and validates recipients properly. Don't. Use some specialized null mailer, I usually use "nullmailer". It will send all e-mail to exactly one smart host. > but > ideally I'd like an invocation of /usr/sbin/sendmail to immediately > send off the email to the relay host and not depend on a permanently > running Postfix daemon. Is this possible? No, it is not possible. Postfix is no single service. Bastian -- Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder", stardate 5928.5.
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On Thu, Aug 06, 2020 at 09:44:24AM +0300, Otto Kekäläinen wrote: > Is it possible to send email using the Postfix provided > /usr/sbin/sendmail command on a system where Postfix is installed, but > not running permanently as a service? Not the upstream Postfix version signed by Wietse. Apple have (had?) a modified Postfix Postfix version that does support idling down when the mail queue is empty. For that you need an "inotify" daemon that watches the queue directory, waking up only as files are added or deleted. It needs to be very robust, never getting out of sync with the queue contents. So long as the maildrop, incoming, active or deferred queues are non-empty, Postfix should be running. Once all four are empty Postfix can be stopped, to be restarted once a new file lands in the maildrop directory. A doable, but perhaps non-trivial, programming project would be to start with Apple's Postfix sources, and port that functionality to BSD and/or Linux. When there's no new mail, the cost of running Postfix is that the queue manager and pickup "wake up" periodically, to scan the queue directory for new messages. This can prevent battery-powered devices from entering an energy-saving sleep mode. Otherwise, provided max_idle is less than the wakeup timer for "pickup", the cost is modest. Postfix idles down to just 3 processes: /usr/local/libexec/postfix/master -w qmgr -l -t unix -u pickup -l -t unix -u with pickup(8) waking up every 60 seconds by default (see master.cf(5)) and qmgr(8) waking up to scan the queue every 300 seconds. You can reduce the cost of qmgr scans by disabling hashing of the deferred queue after stopping Postfix, and then restarting. hash_queue_names = -- Viktor.
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On Thu, Aug 06, 2020 at 02:38:21PM -0400, Viktor Dukhovni wrote: > Otherwise, provided max_idle is less than the wakeup timer for "pickup", > the cost is modest. Postfix idles down to just 3 processes: Correction, typo, max_idle should be *greater* than the wakeup timer for pickup. -- Viktor.
Postfix is no longer forwarding root mail after I changed the forwarding address
I have Postfix setup to automatically forward any mail that goes to root to an external address. I just recently changed my email main email address from a Tutanota one to a Mailbox.org one. I went into /etc/aliases and switched out my addresses there, so now it looks like this: > # See man 5 aliases for format > postmaster: cassidy > > cassidy: poperi...@mailbox.org > root: poperi...@mailbox.org > clamav: root After I did this, I forgot that I had to reload Postfix, so it was still sending mail to my Tutanota account. When I remembered, I did "sudo service postfix restart". Now mail isn't being forwarded to either addresses.
Re: Postfix is no longer forwarding root mail after I changed the forwarding address
did you run 'newaliases'? You shouldn't need to restart postfix to change an alias. RobertC From: owner-postfix-us...@postfix.org on behalf of PopeRigby Sent: Thursday, August 6, 2020 13:51 To: postfix-users@postfix.org Subject: Postfix is no longer forwarding root mail after I changed the forwarding address I have Postfix setup to automatically forward any mail that goes to root to an external address. I just recently changed my email main email address from a Tutanota one to a Mailbox.org one. I went into /etc/aliases and switched out my addresses there, so now it looks like this: > # See man 5 aliases for format > postmaster: cassidy > > cassidy: poperi...@mailbox.org > root: poperi...@mailbox.org > clamav: root After I did this, I forgot that I had to reload Postfix, so it was still sending mail to my Tutanota account. When I remembered, I did "sudo service postfix restart". Now mail isn't being forwarded to either addresses.
Re: Postfix is no longer forwarding root mail after I changed the forwarding address
On Thursday, August 6, 2020 11:55:34 AM PDT Robert Cooper wrote: > did you run 'newaliases'? You shouldn't need to restart postfix to change an > alias. > > > RobertC > > > > > From: owner-postfix-us...@postfix.org on > behalf of PopeRigby Sent: Thursday, August 6, 2020 > 13:51 > To: postfix-users@postfix.org > Subject: Postfix is no longer forwarding root mail after I changed the > forwarding address > > I have Postfix setup to automatically forward any mail that goes to root to > an external address. I just recently changed my email main email address > from a Tutanota one to a Mailbox.org one. I went into /etc/aliases and > switched out > my addresses there, so now it looks like this: > > # See man 5 aliases for format > > postmaster: cassidy > > > > cassidy: poperi...@mailbox.org > > root: poperi...@mailbox.org > > clamav: root > > After I did this, I forgot that I had to reload Postfix, so it was still > sending mail to my Tutanota account. When I remembered, I did "sudo service > postfix restart". Now mail isn't being forwarded to either addresses. No, I didn't. I'll see if that works.
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On 6 Aug 2020, at 14:38, Viktor Dukhovni wrote: A doable, but perhaps non-trivial, programming project would be to start with Apple's Postfix sources, and port that functionality to BSD and/or Linux. Not very doable, because the trigger was handled by launchd, Apple's systemd-like facility. The timed death of the Postfix master process is in the standard distribution (-e option.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)
Re: Using Postfix sendmail without having Postfix daemon running all the time?
On Thu, Aug 06, 2020 at 03:32:11PM -0400, Bill Cole wrote: > > A doable, but perhaps non-trivial, programming project would be to > > start with Apple's Postfix sources, and port that functionality to > > BSD and/or Linux. > > Not very doable, because the trigger was handled by launchd, Apple's > systemd-like facility. The timed death of the Postfix master process is > in the standard distribution (-e option.) That's not a problem, the inotify bit does not *have to* to be part of systemd or similar, it can be a separate queue monitoring process run by systemd or similar. That does leave the possibility of that process not running, but the same can be true of a normal Postfix system. -- Viktor.
