Re: smtpd outgoing mail configuration
On Fri, May 17, 2024 at 08:12:27AM +0200, fr...@lilo.org wrote: How to forward outgoing mail to a remote SMTP server with smtpd? I found this page, but it's out of date I think. https://romanzolotarev.com/openbsd/smtpd-forward.html Tks Pascal I have mine setup like this and its working. My /etc/mail/smtpd.conf: --- start file --- # $OpenBSD: smtpd.conf,v 1.14 2019/11/26 20:14:38 gilles Exp $ # This is the smtpd server system-wide configuration file. # See smtpd.conf(5) for more information. table aliases file:/etc/mail/aliases listen on socket # To accept external mail, replace with: listen on all listen on all action "local_mail" mbox alias action "outbound" relay host smtp://" # Uncomment the following to accept external mail for domain match from # any for domain "" action "local_mail" match from local for local action "local_mail" match from local for any action "outbound" --- End file --- # doas rcctl enable smtpd
Re: smtpd outgoing mail configuration
Den fre 17 maj 2024 kl 08:56 skrev Pascal Deveaux : > > The command > # chown root:_smtpd /etc/mail/secrets > Return : group smtpd doesn't exist The error message doesn't match the command at all, and the _smtpd group has been in the group file for some 15 years. Look for misspellings somewhere. Or a broken /etc/group file that somehow lacks the _smtpd group. -- May the most significant bit of your life be positive.
Re: smtpd outgoing mail configuration
The command # chown root:_smtpd /etc/mail/secrets Return : group smtpd doesn't exist 17 mai 2024 10:32:19 Otto Moerbeek : > On Fri, May 17, 2024 at 08:12:27AM +0200, fr...@lilo.org wrote: > >> How to forward outgoing mail to a remote SMTP server with smtpd? >> >> I found this page, but it's out of date I think. >> https://romanzolotarev.com/openbsd/smtpd-forward.html >> >> Tks >> Pascal > > man smtpd.conf, first exmaple > > -Otto -- Pascal
Re: smtpd outgoing mail configuration
On 17/05/24 11:42, fr...@lilo.org wrote: How to forward outgoing mail to a remote SMTP server with smtpd? I found this page, but it's out of date I think. https://romanzolotarev.com/openbsd/smtpd-forward.html Tks Pascal The config looks fine, use: man smtpd.conf -James
Re: smtpd outgoing mail configuration
On Fri, May 17, 2024 at 08:12:27AM +0200, fr...@lilo.org wrote: > How to forward outgoing mail to a remote SMTP server with smtpd? > > I found this page, but it's out of date I think. > https://romanzolotarev.com/openbsd/smtpd-forward.html > > Tks > Pascal man smtpd.conf, first exmaple -Otto
smtpd outgoing mail configuration
How to forward outgoing mail to a remote SMTP server with smtpd? I found this page, but it's out of date I think. https://romanzolotarev.com/openbsd/smtpd-forward.html Tks Pascal
Re: Why the mail filter?
Yawn On Mon, Dec 25, 2023, 11:05 a.m. wrote: > > On 2023-12-25 06:32, Jan Stary wrote: > > There's nothing to "confront". Go away. > The classic white belief: > "You're not a real man if you're not an obedient worker drone for muh > society (aka women)" > > Fuck you cunt. > I'm glad the taliban and Iran have been slaughtering your kind. > Guess they're "nothing to """confront""" " either. > > Bet you'd say the same thing to someone like Hans Reiser (kernel > programmer (linux)). > And then when he shows you he IS someone to confront; > then he gets criticized from the other direction. > > There's no winning with you fucking faggots. > You're simply a woman's society. > > Glad you lost in afghanistan :) > > Men are _FUCKING_ their young girl brides there. > White CUNT. > > Oh: and please some help with Unreal Map format loading: > sf.net/p/chaosesqueanthology/tickets/2/ > > On 2023-12-25 06:32, Jan Stary wrote: > > There's nothing to "confront". Go away. > > > > On Dec 25 05:31:13, mikee...@firemail.cc wrote: > >> Got a problem with my emails? Can't confront me man to man? Like > >> fucking > >> faggot scum? > >> > >> > >
Re: Why the mail filter?
On 2023-12-25 06:32, Jan Stary wrote: There's nothing to "confront". Go away. The classic white belief: "You're not a real man if you're not an obedient worker drone for muh society (aka women)" Fuck you cunt. I'm glad the taliban and Iran have been slaughtering your kind. Guess they're "nothing to """confront""" " either. Bet you'd say the same thing to someone like Hans Reiser (kernel programmer (linux)). And then when he shows you he IS someone to confront; then he gets criticized from the other direction. There's no winning with you fucking faggots. You're simply a woman's society. Glad you lost in afghanistan :) Men are _FUCKING_ their young girl brides there. White CUNT. Oh: and please some help with Unreal Map format loading: sf.net/p/chaosesqueanthology/tickets/2/ On 2023-12-25 06:32, Jan Stary wrote: There's nothing to "confront". Go away. On Dec 25 05:31:13, mikee...@firemail.cc wrote: Got a problem with my emails? Can't confront me man to man? Like fucking faggot scum?
Re: Why the mail filter?
There's nothing to "confront". Go away. On Dec 25 05:31:13, mikee...@firemail.cc wrote: > Got a problem with my emails? Can't confront me man to man? Like fucking > faggot scum? > >
Why the mail filter?
Got a problem with my emails? Can't confront me man to man? Like fucking faggot scum?
Re: Claws Mail and new call for eu locale
Hi, Daniele B. wrote on Wed, Nov 15, 2023 at 06:17:21PM +0100: > I just came accross the last little problem regarding the locale of my > system: in Claws Mail the date in message pane is displayed in %x > format (result=mm/dd/year) to adapt to the current locale. > > I started to change locale to my system in all the possible ways > without luck. If I set it_IT I got yes the right language but the same > result for the date (in the message pane). > > In the end going in Claws Mail display settings the option allows me > to specify the parameters for the date format. "man strftime" I found > something useful (an year/mm/dd), although not exactly a simple > dd/mm/year format yet. > > Dispite these details and knowing that en_US.UTF-8 with "C" locale > profile is reccomnded to us, I take the time to gently ask about > the support for any european date locale profile and any feedback > about any eventual work-in-progress? Even if someone would provide libc patches to provide LC_* support other than LC_CTYPE, i would veto them, even if they were correct and very simple (they cannot be simple, though). Reliable and predictable output is much more important than such quibbles. The C library is totally the wrong place for any such functionality. Yours, Ingo
Proton Mail Bridge
Someone reached out to me this morning asking if I use Proton Mail from within my OpenBSD system, but I told them I'm just using it on my iPhone. but I took a look, and their bridge application is open source. https://github.com/ProtonMail/proton-bridge I downloaded and added the necessary packages: gmake, gcc, go; but it died because there's no setup files for OpenBSD. Proton Mail Bridge is an application that opens IMAP and SMTP ports on the local machine and acts as an intermediary between your mail client and the Proton servers. I'd love to get this working. Has anyone played with it? -- "Love endures everything, love is stronger than death, love fears nothing." Maria Faustina Kowalska
Re: mail command - change "from address" for Charlie Root
Hello, Thank you Todd, that information was quite helpful. I created /var/log/.mailrc. The from header is working. Nino > On 7 May 2023, at 12:07 am, Todd C. Miller wrote: > > On Sat, 06 May 2023 10:03:45 +1000, Nino Sidoti wrote: > >> I am trying to work out how to change the “From address” for when the daily o >> utput reports are run. I want to use a real email address rather than the def >> ault of Charlie Root “root@hostname”. >> >> I have tried to use a /root/.mailrc option and set the “from” address but thi >> s seems to be ignored when the daily output reports are generated. > > That is probably because the root crontab sets HOME to /var/log. > You might try creating a /var/log/.mailrc file (owned by root) and > see if that works for you. If not, you might just edit /etc/daily > and pass the -r option to mail to set the from address. > > - todd
Re: mail command - change "from address" for Charlie Root
On Sat, 06 May 2023 10:03:45 +1000, Nino Sidoti wrote: > I am trying to work out how to change the “From address” for when the daily o > utput reports are run. I want to use a real email address rather than the def > ault of Charlie Root “root@hostname”. > > I have tried to use a /root/.mailrc option and set the “from” address but thi > s seems to be ignored when the daily output reports are generated. That is probably because the root crontab sets HOME to /var/log. You might try creating a /var/log/.mailrc file (owned by root) and see if that works for you. If not, you might just edit /etc/daily and pass the -r option to mail to set the from address. - todd
Re: mail command - change "from address" for Charlie Root
Am 06.05.2023 02:03 schrieb Nino Sidoti: Hello, I am trying to work out how to change the “From address” for when the daily output reports are run. I want to use a real email address rather than the default of Charlie Root “root@hostname”. It takes the name from /etc/passwd. See vipw(8) for changing it. -- pb
mail command - change "from address" for Charlie Root
Hello, I am trying to work out how to change the “From address” for when the daily output reports are run. I want to use a real email address rather than the default of Charlie Root “root@hostname”. I have tried to use a /root/.mailrc option and set the “from” address but this seems to be ignored when the daily output reports are generated. I send the daily reports to my personal email and have configure /etc/mail/aliases so that “root” is using my personal email. I am using openBSD 7.3 AMD64. Thank you
Re: Mail Etiquette: Reply above or below
It makes it easier to know what part of the original message a response is in reply to. As a general rule you should reply in-line, quoting only the specific parts of a message your response is in reference to. Matthew Eric Johnson writes: > --- Original Message --- > On Tuesday, March 7th, 2023 at 03:50, Peter N. M. Hansteen > wrote: > > > For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail > > client products dragged in a convention of quoting the whole thread (even > > though > > those early clients did not in fact have the thread concept) and putting new > > text on top. > > Don't forget AOL. In the old UseNet days, AOLers seemed to > be the ones who most insisted on top posting and it drove the > rest of us crazy. > > I'm not positive, but I think that the AOL software handled > the mail and Microsoft came around to it somewhat later. > > I have come around to the point that I don't mind top posting > if the remarks pretty much stand on their own and only address > a single point. It even saves scrolling down to the bottom to > read the comments, especially if the person being responded to > didn't snip those parts that don't really relate to the comments > being made. > > But you are right that inline is the way to go for anything > suitably complicated in order to eliminate any chance of > someone else getting confused about what is being referred > to by the comment. > > In one web forum that I participate in, there are a few users > who will quote the message being replied to and then insert > their comments intermixed within the quoted part instead of > separating the quotes out in pieces to avoid the reader from > being seriously confused over who said what. I really hate > it when they do that. > > So in response, I sometimes write my replies using the > character code sequences such as for J. That way, it > forces those who can't be bothered to separate their comments > from the quoted text to keep their text separate. > > I think that the main point is that the purpose of writing > is so that others may understand what you had to say. The > more difficult that someone makes it to decipher what they > wrote, the more people won't even bother with them. > > Eric Why?
Re: Mail Etiquette: Reply above or below
--- Original Message --- On Tuesday, March 7th, 2023 at 03:50, Peter N. M. Hansteen wrote: > For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail > client products dragged in a convention of quoting the whole thread (even > though > those early clients did not in fact have the thread concept) and putting new > text on top. Don't forget AOL. In the old UseNet days, AOLers seemed to be the ones who most insisted on top posting and it drove the rest of us crazy. I'm not positive, but I think that the AOL software handled the mail and Microsoft came around to it somewhat later. I have come around to the point that I don't mind top posting if the remarks pretty much stand on their own and only address a single point. It even saves scrolling down to the bottom to read the comments, especially if the person being responded to didn't snip those parts that don't really relate to the comments being made. But you are right that inline is the way to go for anything suitably complicated in order to eliminate any chance of someone else getting confused about what is being referred to by the comment. In one web forum that I participate in, there are a few users who will quote the message being replied to and then insert their comments intermixed within the quoted part instead of separating the quotes out in pieces to avoid the reader from being seriously confused over who said what. I really hate it when they do that. So in response, I sometimes write my replies using the character code sequences such as for J. That way, it forces those who can't be bothered to separate their comments from the quoted text to keep their text separate. I think that the main point is that the purpose of writing is so that others may understand what you had to say. The more difficult that someone makes it to decipher what they wrote, the more people won't even bother with them. Eric
Re: Mail Etiquette: Reply above or below
On Tue, 7 Mar 2023 23:47:54 +0100 (GMT+01:00) "Daniele B." wrote: > I'd like to state that unfortunately sometimes it is simply > that we forget to deselect/delete the whole quoted text from the bottom and > this > why almost in my case both the selected quoted text and the full > text appear - depending on the client. Some email clients (e.g. both Claws Mail and Thunderbird), allow you to highlight a piece of text in an email, hit reply, and it'll include *just* that block of quoted text. Handy for situations like this. Sadly, not sure about text-based clients, I don't think `mutt` can for example, but I would love to be shown otherwise on that. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
[OT] Re: Mail Etiquette: Reply above or below
On Tue, 7 Mar 2023 09:36:10 + (UTC) Johannes Thyssen Tishman wrote: > When I reply to an email I do so above the senders message, however I > see many people in the mailing lists replying below it. Is this the > preferred way or just preference? Thanks. It comes down to this, if you're posting above the quote, you're basically (intentionally or not) saying "the context does not matter". The exception to this would be if the thread is written in a language that is read bottom to top, in which case, replying above the quote would be the better system. English is not a language read bottom to top. There might be one or two that are, but I personally do not know of any. If you post below, it's clearly a two-way discussion. Interleaving replies helps a busy person "remind" themselves of what you're replying to instead of scanning up/down/up/down and having to mentally piece the discussion together from top-posted replies. To this day I do not know why "business" people prefer the other style, then consistently moan about how distracting email is. My only guess is I think they forgot that this is an electronic file so it's possible to verbatim quote someone's paragraphs and append your reply below unlike dead-tree snail mail, where you'd have to re-write what the other party said (or involving a photocopier, some scissors and some glue in the process). Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Mail Etiquette: Reply above or below
On Tue, Mar 07, 2023 at 11:58:14AM +0100, Christer Solskogen wrote: Someone way smarter than me said this: Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail? You sure? ... Quoting Nick Holland: " Bottom posting was invented for those who can't write in complete thoughts with context. You know, like most of the computer world. :-/ " https://marc.info/?l=openbsd-misc=157503288130311=mbox
Re: Mail Etiquette: Reply above or below
I'd like to state that unfortunately sometimes it is simply that we forget to deselect/delete the whole quoted text from the bottom and this why almost in my case both the selected quoted text and the full text appear - depending on the client. Talking about email clients I want to spread the voice (one more time farther then Tom, the owner of Misc) about my actual choice for Android: FairEmail https://email.faircode.eu absolutely recommended! No relationship with it but honestly hay and endorsing it. :D -- Daniele Bonini
Re: Mail Etiquette: Reply above or below
On 2023-03-07 04:50, Peter N. M. Hansteen wrote (in part): For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail client products dragged in a convention of quoting the whole thread (even though those early clients did not in fact have the thread concept) and putting new text on top. Indeed. When I was forced to use Outlook (or LookOut! as some wrote) and needed to answer in parts, I copied the entire content into a real editor first. (This caused problems with people who used multiple fonts.) S. I think this would point to my preference at least. Cue my 2011 rant about same, enjoy: https://bsdly.blogspot.com/2011/02/problem-isnt-email-its-microsoft.html All the best, Peter
Re: Mail Etiquette: Reply above or below
On Tue, Mar 07, 2023 at 10:50:44AM +0100, Peter N. M. Hansteen wrote: > On Tue, Mar 07, 2023 at 09:36:10AM +, Johannes Thyssen Tishman wrote: > > > > When I reply to an email I do so above the senders message, however I see > > many people in the mailing lists replying below it. Is this the preferred > > way or just preference? Thanks. > > The traditional style is to quote only the parts of the previous message(s) > that you are writing in respose to. > > If you are commenting on several parts of a previous exchange, the convention > would be to offer your own input in several blocks, directly following the > parts you are responding to. > > For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail > client products dragged in a convention of quoting the whole thread (even > though > those early clients did not in fact have the thread concept) and putting new > text on top. Of course it had to be Microsoft. > > I think this would point to my preference at least. Cue my 2011 rant about > same, enjoy: > https://bsdly.blogspot.com/2011/02/problem-isnt-email-its-microsoft.html Thanks, will check it out :) > > All the best, > Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > -- Johannes Thyssen Tishman E-Mail: johan...@thyssentishman.com Website: thyssentishman.com
Re: Mail Etiquette: Reply above or below
Hello Johannes, Firstly, others have written helpful and correct responses, please follow these suggestions. Those replies also look perfect and are easy to follow in my personal mail client (which is Outlook). For the record, there are members of this community that couldn't care less if someone top-posts, bottom-posts, inline posts, side-posts, reverse posts, private posts, 3D posts, Saturn posts, etc. However, this is likely a minority, and there are community guidelines as others have pointed out. Personally, my responses are usually focussed responses to a particular question/comment (which I often put in quotation marks because I don't care for the ">" everywhere, I mean, we're still allowed to have preferences) or fairly extensive rants, which are comprehensive responses to the whole topic/thread. Speaking of standardizing every aspect of the netiquette on the mailing list, can we please reserve quotation marks for actual quotations and use apostrophes instead for 'random use'? (I'm joking, but this standardization of email exchange can become a slippery slope). I'm not saying that these approaches are correct or condoning them, but they have not gotten me into horrible trouble (and I'm a member of many OSS mailing lists) and have still allowed for helpful engagement. This likely says something very positive about the communities. Again, I am not condoning this. We all use different mail clients. What I find annoying, and it is no one's fault here (well, it actually could be, but I'm not going to point any fingers), are mailing-list emails where all I see is three horizontal dots when I open the message (see: Claudio Jeker's response to the "Folks are there any tips to improve page load times on smokeping running on OpenBSD" thread in Outlook). I realize this is my mail client. It is a correct way of doing e-mail correspondence. Still, as with many things, MS has made it incredibly annoying. Sincerely, Katie From: owner-m...@openbsd.org on behalf of Zé Loff Sent: 07 March 2023 05:39 To: Johannes Thyssen Tishman Cc: misc@openbsd.org Subject: Re: Mail Etiquette: Reply above or below Attention : courriel externe | external email On Tue, Mar 07, 2023 at 09:36:10AM +, Johannes Thyssen Tishman wrote: > Hi, > > When I reply to an email I do so above the senders message, however I > see many people in the mailing lists replying below it. Is this the > preferred way or just preference? Thanks. > > Kind regards, > Johannes For OpenBSD's mailing lists, the netiquette rules are clearly presented here https://www.openbsd.org/mail.html. Another unwritten rule (and not exclusive to these lists, I'd say) is that if someone replies off-list you *don't* reply back through the list (i.e. you don't "pull" the reply back in to the list), at least not without asking first. There's probably a reason for someone not wanting their reply made public (otherwise they wouldn't have gone off-list) and it's rude to publish a private exchange. Cheers Zé --
Re: Mail Etiquette: Reply above or below
Johannes Thyssen Tishman writes: > Hi, Hello, > When I reply to an email I do so above the senders message, however I > see many people in the mailing lists replying below it. Is this the > preferred way or just preference? Thanks. Yes, there are "top-posting", "bottom posting" and "inline posting", "inline posting" is the preferred way. See: https://www.mediawiki.org/wiki/Mailing_list_etiquette
Re: Mail Etiquette: Reply above or below
On Tue, Mar 7, 2023 at 10:37 AM Johannes Thyssen Tishman wrote: > > Hi, > > When I reply to an email I do so above the senders message, however I see > many people in the mailing lists replying below it. Is this the preferred way > or just preference? Thanks. > Someone way smarter than me said this: Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail? -- chs
Re: Mail Etiquette: Reply above or below
On Tue, Mar 07, 2023 at 09:36:10AM +, Johannes Thyssen Tishman wrote: > Hi, > > When I reply to an email I do so above the senders message, however I > see many people in the mailing lists replying below it. Is this the > preferred way or just preference? Thanks. > > Kind regards, > Johannes For OpenBSD's mailing lists, the netiquette rules are clearly presented here https://www.openbsd.org/mail.html. Another unwritten rule (and not exclusive to these lists, I'd say) is that if someone replies off-list you *don't* reply back through the list (i.e. you don't "pull" the reply back in to the list), at least not without asking first. There's probably a reason for someone not wanting their reply made public (otherwise they wouldn't have gone off-list) and it's rude to publish a private exchange. Cheers Zé --
Re: Mail Etiquette: Reply above or below
2023-03-07T09:52:48Z 宋文武 : > Johannes Thyssen Tishman writes: > >> Hi, > > Hello, > >> When I reply to an email I do so above the senders message, however I >> see many people in the mailing lists replying below it. Is this the >> preferred way or just preference? Thanks. > > Yes, there are "top-posting", "bottom posting" and "inline posting", > "inline posting" is the preferred way. Understood! Thank you very much :) > See: https://www.mediawiki.org/wiki/Mailing_list_etiquette
Re: Mail Etiquette: Reply above or below
On Tue, Mar 07, 2023 at 09:36:10AM +, Johannes Thyssen Tishman wrote: > > When I reply to an email I do so above the senders message, however I see > many people in the mailing lists replying below it. Is this the preferred way > or just preference? Thanks. The traditional style is to quote only the parts of the previous message(s) that you are writing in respose to. If you are commenting on several parts of a previous exchange, the convention would be to offer your own input in several blocks, directly following the parts you are responding to. For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail client products dragged in a convention of quoting the whole thread (even though those early clients did not in fact have the thread concept) and putting new text on top. I think this would point to my preference at least. Cue my 2011 rant about same, enjoy: https://bsdly.blogspot.com/2011/02/problem-isnt-email-its-microsoft.html All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Mail Etiquette: Reply above or below
Hi, When I reply to an email I do so above the senders message, however I see many people in the mailing lists replying below it. Is this the preferred way or just preference? Thanks. Kind regards, Johannes
Re: Mail from the command line
2023-02-18 13:44 GMT, Crystal Kolipe : > On Sat, Feb 18, 2023 at 12:47:46PM +, Rodrigo Readi wrote: > Not really. I just described the way that mail is traditionally handled on > a unix workstation, and that still works for a large proportion of users, > myself included. Perhaps not on a workstation, but on a Mainframe, Minicomputer, or just a server. Most people using UNIXoids today do it on "Desktops". They do not have a static IP, their computers are also not an X Terminal. They are just a "Personal Computer", many of them a laptop, and now smartphones. > But you have found that in practice this is not always the case, because > the clients that are available and which broadly implement the standards don't > provide the specific sub-features that you want, such as downloading just > the text part without attachments over IMAP. I was speaking about CLI clients. >> And I repeat, IMAP is not POP3, it is not for retrieving all mails, > > But it [IMAP] can be used for that purpose, and there are good reasons to > prefer it > over POP3 for retrieving all mails because it supports push via the IDLE > command and therefore avoids the need to poll at short intervals. I prefer to retrieve the last headers when I want to read email, you prefer to keep the connection alive. It is a matter of taste. > Since by your own definition, CLI clients are not adapted to your way of > working, but rather still favour the traditional way of downloading all > mail > to a local mail spool, why would it make sense to assume that somebody > asking > about CLI clients and not mentioning remote or mobile access, has these > requirements and has a similar way of working to yours? Good question. I do not know exactly what the OP wants. Perhaps he can say it? Rod.
Re: Mail from the command line
On Sat, Feb 18, 2023 at 12:47:46PM +, Rodrigo Readi wrote: > 2023-02-18 9:47 GMT, Crystal Kolipe : > > Now things have changed, > > Have changed for YOU. It is your solution for your specific way of working > at your place, less mobile. Not really. I just described the way that mail is traditionally handled on a unix workstation, and that still works for a large proportion of users, myself included. > > But locking new users in to using specific programs from ports in order to > > give them a quick answer is not a great solution. In the future they'll > > find > > themselves saying, "I have to use mail client FOO on OpenBSD, because it's > > the only one that supports BAR, which I've come to rely on". > > No. For that there are standards. Here SMTP for sending, IMAP for getting. > You can use any client that follows the standards. But you have found that in practice this is not always the case, because the clients that are available and which broadly implement the standards don't provide the specific sub-features that you want, such as downloading just the text part without attachments over IMAP. > And I repeat, IMAP is not POP3, it is not for retrieving all mails, But it can be used for that purpose, and there are good reasons to prefer it over POP3 for retrieving all mails because it supports push via the IDLE command and therefore avoids the need to poll at short intervals. A very long time ago, I wrote a ~23 Kb perl script to do exactly that, and on the rare occasions that I need to monitor mail from external servers which are not under our direct control and to which I only have POP3/IMAP access, it works fine. > and it was invented for good reasons. > > Unfortunately CLI clients are not being adapted to today's requirements. The OP asked about using mail from the command line without elaborating on his specific configuration, (fixed or mobile, ISP, etc). Since by your own definition, CLI clients are not adapted to your way of working, but rather still favour the traditional way of downloading all mail to a local mail spool, why would it make sense to assume that somebody asking about CLI clients and not mentioning remote or mobile access, has these requirements and has a similar way of working to yours? > Alpine seems to have only one developer. I'm sure they would be happy to receive patches from you :-).
Re: Mail from the command line
2023-02-18 9:47 GMT, Crystal Kolipe : > On Sat, Feb 18, 2023 at 12:50:05AM +, Rodrigo Readi wrote: > When I sit down at my workstation, all of my email is just there. New > mail, complete with all attachments, arrived whilst I was away making coffee > or > whatever, so the download time didn't affect me - it was not done > interactively. You SIT at YOUR workstation. In between you MAKE COFFEE. > Now things have changed, Have changed for YOU. It is your solution for your specific way of working at your place, less mobile. > But locking new users in to using specific programs from ports in order to > give them a quick answer is not a great solution. In the future they'll > find > themselves saying, "I have to use mail client FOO on OpenBSD, because it's > the only one that supports BAR, which I've come to rely on". No. For that there are standards. Here SMTP for sending, IMAP for getting. You can use any client that follows the standards. And I repeat, IMAP is not POP3, it is not for retrieving all mails, and it was invented for good reasons. Unfortunately CLI clients are not being adapted to today's requirements. Alpine seems to have only one developer. Rod.
Re: Mail from the command line
On Sat, Feb 18, 2023 at 12:50:05AM +, Rodrigo Readi wrote: > The OP wanted a simple solution The OP just asked how to use '$ mail on the command line'. This is not very specific, which is why I asked exactly what he was trying to do in my first reply. > and the answers are getting too complicated. [...] > But my mail does not go through my server, but through 3 party providers. > And I want to use IMAP for what it is on my Desktops, and IMAP is not POP3. > > I first see the headers, then I decide for what mail I want to read > the text, and then > for that mail what attachements. I can see the emails on the server with any > Desktop computer anywhere. For that is IMAP. That doesn't sound at all like a simple solution to me. When I sit down at my workstation, all of my email is just there. New mail, complete with all attachments, arrived whilst I was away making coffee or whatever, so the download time didn't affect me - it was not done interactively. I can browse and search all email at the speed of my local disk, using _any_ client program with virtually no special configuration of new clients required. Many years ago, when sendmail was the common MTA on unix-like systems, it was reasonable to tell users, "If you're coming from a non-unix background and want it to 'just work' in a hurry, then use one of the desktop clients". This made sense for new users who had been using Netscape Communicator on another platform, and could use exactly the same application on X. Now things have changed, and configuring smtpd for outgoing mail shouldn't be much of a challenge for anyone with basic experience of OpenBSD. Inbound mail is more complicated because, as I explained before, it depends on the ISP and also your expectations of how the system is going to work. But locking new users in to using specific programs from ports in order to give them a quick answer is not a great solution. In the future they'll find themselves saying, "I have to use mail client FOO on OpenBSD, because it's the only one that supports BAR, which I've come to rely on".
Re: Mail from the command line
2023-02-17 23:50 GMT, Crystal Kolipe : > On Fri, Feb 17, 2023 at 10:02:16PM +, Rodrigo Readi wrote: >> But the main problem remains: with s-nail and mutt you have to >> download all attachments >> even if you only want to read the text. > > Out of interest, why is this an issue in your specific use case? Yes, bandwidth and speed play a big role. Yes, I could download all emails with fetchmail or mbsync. Yes, I could use an Email server, and I have one running, with sendmail and cyrusimap. But my mail does not go through my server, but through 3 party providers. And I want to use IMAP for what it is on my Desktops, and IMAP is not POP3. I first see the headers, then I decide for what mail I want to read the text, and then for that mail what attachements. I can see the emails on the server with any Desktop computer anywhere. For that is IMAP. The OP wanted a simple solution, and the answers are getting too complicated.
Re: Mail from the command line
Rodrigo Readi wrote in : |2023-02-17 19:16 GMT, Steffen Nurpmeso : |>|>> modern requirements (html-mail, attachements). |> |> These both s-nail can (the former likely via mailcap). | |Yes, as I did it with BSD mail. | |But the main problem remains: with s-nail and mutt you have to |download all attachments |even if you only want to read the text. | |Alpine source comes with the old (unfortunately unmantained) UW imap, |the reference |implementation of imap. Alpine client has better imap support. S-nail surely has the weakest IMAP support of the three. mutt can for example use IMAP compression. (Other than that i do not know much of their sources, even though i track both git's.) Well. S-nail can fetch only headers, but if you want to read/save/xy a message then the entire content is downloaded. Maybe an idea to keep in mind for (much) later. For me personally this is uninteresting, i pre-filter on the server and the rest i fetch from within S-nail via SSH, like that i do not need an additional IMAP daemon :). (Actually the development version contains undocumented code to trim messages, one could store and download the trimmed ones. This was meant for a mailing-list implemenation hack that yet did not spring into existence. Whatever.) Well i do not know, mostly if i want to read an email as via looking at the header i need it all; my SMTP server also has a strict size limit, and moreover do not receive (a lot of) multimedia attachments. If, that would surely be a problem. I find that unfriendly, one sometimes sees that on OpenBSD @misc, or huge tgz on @ports; i'd rather like to see an external URL then. There is even an email standard for that, message/external-body;access-type=URL (RFC 2017). But any URL would do. |And xoath2 for gmail is other story. I regret that I began using gmail. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
On Fri, Feb 17, 2023 at 10:02:16PM +, Rodrigo Readi wrote: > But the main problem remains: with s-nail and mutt you have to > download all attachments > even if you only want to read the text. Out of interest, why is this an issue in your specific use case? Is it due to bandwidth usage, (I.E. you are on a metered connection and want to reduce data usage), or is it due to speed, in other words browsing through your inbox is slower than it needs to be due to downloading all attachments instead of just the text part? Storing your mail long-term on a remote server and accessing it via a remote mail access protocol such as IMAP has some convenient perks, but it's by no means the only practical way of working. If you're hitting up against it's limitations then maybe it's time to consider the alternative. If you're not on a metered connection, then having 'real' mail delivery via SMTP right to your desktop or a local mailserver, makes browsing and searching your mailspools faster than it will ever likely be over an internet based IMAP connection. If you need remote access to your mail, there are ways to do this from your own server, and if you don't want to or can't set up inbound SMTP then there are ways to pull mail using POP3 or IMAP and feed it in to the local mail spool.
Re: Mail from the command line
2023-02-17 19:16 GMT, Steffen Nurpmeso : > |>> modern requirements (html-mail, attachements). > > These both s-nail can (the former likely via mailcap). Yes, as I did it with BSD mail. But the main problem remains: with s-nail and mutt you have to download all attachments even if you only want to read the text. Alpine source comes with the old (unfortunately unmantained) UW imap, the reference implementation of imap. Alpine client has better imap support. And xoath2 for gmail is other story. I regret that I began using gmail. Rod.
Re: Mail from the command line
Steffen Nurpmeso wrote in <20230217191605.lu6ph%stef...@sdaoden.eu>: |deich...@placebonol.com wrote in | <11709eb8-1507-4c76-a042-4c1d016e4...@placebonol.com>: ... ||>> And alpine is easier to configure, it works with gmail's xoauth2, Btw i have written a python3 script that can GMail, Outlook and Yandex, and possibly can more. (It is easier to configure than that mutt script in contrib/, or the one one can find in the internet for sendmail oauth, and it works with modern Python3, different to the one that Google provides. The "template" mode writes a template with doc comments.) curl -u moon:mars --basic -O https://git.sdaoden.eu/browse/s-toolbox.git/plain/oauth-helper.py --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
deich...@placebonol.com wrote in <11709eb8-1507-4c76-a042-4c1d016e4...@placebonol.com>: |Also take a look at s-nail, it is not an email application, but a very \ |useful utility. It is BSD Mail on steroids i would say in "Theo" mode. (Though a lot is to be done. And unveil() and pledge() even further apart.) |diana Greetings. |On February 17, 2023 9:13:15 AM MST, Andrew Mitchell \ |wrote: |>Thanks, I'll check it out. |>Andrew |> |>Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : |> |>> 2023-02-16 13:42 GMT, Andrew : |>>> Thanks Crystal for your reply and encouragement, |>>> I'll explore all your suggestions and references when I have enough \ |>>> time. |>> |>> If you do not have tine, better install and use alpine. |>> |>> You can read mail from a provider with imap without having to download |>> the attachements. |>> Mutt is not able to do that. |>> |>> And alpine is easier to configure, it works with gmail's xoauth2, That can be done with mutt, too. |>> displays html-mail. This is a MIME (mailcap) handler. |>> I like BSD mail program, but unfortunately it is not always (easily) |>> usable due to the |>> modern requirements (html-mail, attachements). These both s-nail can (the former likely via mailcap). --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
Also take a look at s-nail, it is not an email application, but a very useful utility. 73 diana On February 17, 2023 9:13:15 AM MST, Andrew Mitchell wrote: >Thanks, I'll check it out. >Andrew > >Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : > >> 2023-02-16 13:42 GMT, Andrew : >> > Thanks Crystal for your reply and encouragement, >> > I'll explore all your suggestions and references when I have enough time. >> >> If you do not have tine, better install and use alpine. >> >> You can read mail from a provider with imap without having to download >> the attachements. >> Mutt is not able to do that. >> >> And alpine is easier to configure, it works with gmail's xoauth2, >> displays html-mail. >> >> I like BSD mail program, but unfortunately it is not always (easily) >> usable due to the >> modern requirements (html-mail, attachements). >> >> Rod. >>
Re: Mail from the command line
Thanks, I'll check it out. Andrew Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : > 2023-02-16 13:42 GMT, Andrew : > > Thanks Crystal for your reply and encouragement, > > I'll explore all your suggestions and references when I have enough time. > > If you do not have tine, better install and use alpine. > > You can read mail from a provider with imap without having to download > the attachements. > Mutt is not able to do that. > > And alpine is easier to configure, it works with gmail's xoauth2, > displays html-mail. > > I like BSD mail program, but unfortunately it is not always (easily) > usable due to the > modern requirements (html-mail, attachements). > > Rod. >
Re: Mail from the command line
2023-02-16 13:42 GMT, Andrew : > Thanks Crystal for your reply and encouragement, > I'll explore all your suggestions and references when I have enough time. If you do not have tine, better install and use alpine. You can read mail from a provider with imap without having to download the attachements. Mutt is not able to do that. And alpine is easier to configure, it works with gmail's xoauth2, displays html-mail. I like BSD mail program, but unfortunately it is not always (easily) usable due to the modern requirements (html-mail, attachements). Rod.
Re: Mail from the command line
Thanks Crystal for your reply and encouragement, I'll explore all your suggestions and references when I have enough time. Cheers, Andrew Le jeu. 16 févr. 2023 à 12:58, Crystal Kolipe a écrit : > On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > > *Do you know any recipe for using $ mail on the command line? Or a web > link > > that proposes one.* > > > > The man pages are great but they are meant for people with great > technical > > skills, which I am not. > > What exactly are you trying to set up? > > Local mail works out of the box on a default OpenBSD install, so I'm > assuming > that what you want to do is to send and receive mail to other internet > hosts > without using a desktop/gui client, I.E. using the traditional built-in > mail > functionality typical of a unix-like system. > > This isn't particularly difficult, but it does depend to a certain extent > on > the configuration of your ISP, and also exactly how you want the system to > behave. So it's not possible to give you a simple fixed list of steps to > follow to 'make it work'. > > First up, the /usr/bin/mail utility in base is really a hard link to > /usr/bin/mailx. > > This is a very simple command line mail tool, which you probably don't > want to > use as your mail email application because it's lacking many features. > > Other command line based mail programs are available in ports, such as > mutt, > which is widely used by openbsd developers. > > Then you need to set up smtpd to handle your inbound and outbound mail. > > For outbound mail, you _probably_ want to, (and need to), relay it via your > ISP's 'smarthost', but we would need more information to know this for > certain > and to give specific advice on how to set it up. > > For inbound mail, you have several choices: > > * Run your own MX on a fixed IP broadband link. > * Pick up your mail via POP3 or IMAP from within the mail user agent, > (such as > mutt), and feed it in to your local mail spools that way. > * Pick up your mail via POP3 or IMAP and feed it into the local mail > system. > * Run your own MX on your own server or VM somewhere, and relay it to your > own local, private MX. > * Other options also exist. > > If you are new to this, then you probably want the second option. Maybe > the > third. > > > And web pages are full of phoney tips which rarely work. > > Agreed. > > > I hope that this is the right place for asking such questions. > > Yes, it is. > > But we can't give you a step-by-step guide without a bit more information. >
Re: Mail from the command line
On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > *Do you know any recipe for using $ mail on the command line? Or a web link > that proposes one.* > > The man pages are great but they are meant for people with great technical > skills, which I am not. What exactly are you trying to set up? Local mail works out of the box on a default OpenBSD install, so I'm assuming that what you want to do is to send and receive mail to other internet hosts without using a desktop/gui client, I.E. using the traditional built-in mail functionality typical of a unix-like system. This isn't particularly difficult, but it does depend to a certain extent on the configuration of your ISP, and also exactly how you want the system to behave. So it's not possible to give you a simple fixed list of steps to follow to 'make it work'. First up, the /usr/bin/mail utility in base is really a hard link to /usr/bin/mailx. This is a very simple command line mail tool, which you probably don't want to use as your mail email application because it's lacking many features. Other command line based mail programs are available in ports, such as mutt, which is widely used by openbsd developers. Then you need to set up smtpd to handle your inbound and outbound mail. For outbound mail, you _probably_ want to, (and need to), relay it via your ISP's 'smarthost', but we would need more information to know this for certain and to give specific advice on how to set it up. For inbound mail, you have several choices: * Run your own MX on a fixed IP broadband link. * Pick up your mail via POP3 or IMAP from within the mail user agent, (such as mutt), and feed it in to your local mail spools that way. * Pick up your mail via POP3 or IMAP and feed it into the local mail system. * Run your own MX on your own server or VM somewhere, and relay it to your own local, private MX. * Other options also exist. If you are new to this, then you probably want the second option. Maybe the third. > And web pages are full of phoney tips which rarely work. Agreed. > I hope that this is the right place for asking such questions. Yes, it is. But we can't give you a step-by-step guide without a bit more information.
Re: Mail from the command line
On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > > *Do you know any recipe for using $ mail on the command line? Or a web link > that proposes one.* typing "using mail from the command line" into a search engine yields quite a few hits. This one https://phoenixnap.com/kb/linux-mail-command looks like a fairly useful one once you skip the "how to install mailx on Linux" part. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Mail from the command line
Hi Misc, I'm so sorry guys if that question has been asked too often. *Do you know any recipe for using $ mail on the command line? Or a web link that proposes one.* The man pages are great but they are meant for people with great technical skills, which I am not. And web pages are full of phoney tips which rarely work. I hope that this is the right place for asking such questions. Cheers, Andrew
Re: Why some mail were lost, is this common?
If you need a good email provider, Proton is worth it. I had no issue with them(related to sending/receiving/uptime), but they are a bit pricey. Also the really good encryption is a bonus. The single issue I have, is dealing with the bridge. --- Original Message --- On Friday, February 10th, 2023 at 8:11 PM, Luke A. Call wrote: > > > pair.com also seems to work well as a mail provider (online, pop, or > imap, no weird games). > > On 2023-02-10 12:39:13+0800, Adriel Peng peng.adr...@gmail.com wrote: > > > Hmm I am the person working for email delivery. > > don't use mail.ru who blocks a lot of lists mail every day. > > Use gmail instead. If gmail is unavailable in your country, then try > > Fastmail/riseup/GMX etc, or even the new one OpenMbox.net > > > > Regards > > > > On Fri, Feb 10, 2023 at 10:06 AM Digua Dong dongdig...@mail.ru wrote: > > > > > hello > > > new to mailing list > > > > > > I'm previously using zohomail.cn and some of email from mailing list are > > > lost. > > > I thought, it is in China, so probably because of GFW? > > > And one weird thing: if I delete Notification folder, I can't receive any > > > mail. > > > > > > Then I switched to mail.ru, but still can't get the mailing list full! > > > They're not in Spam() folder, just got lost. > > > > > > I don't want to frequently switch mail service and wait for new mail > > > and compare with marc.info to judge if it is ok. > > > > > > Does anyone have the same issue / is this a common thing? > > > What is probably going wrong? > > > > > > digua publickey - cristiioan@cristiioan.me - 0xDAC92D89.asc Description: application/pgp-keys
Re: Why some mail were lost, is this common?
pair.com also seems to work well as a mail provider (online, pop, or imap, no weird games). On 2023-02-10 12:39:13+0800, Adriel Peng wrote: > Hmm I am the person working for email delivery. > don't use mail.ru who blocks a lot of lists mail every day. > Use gmail instead. If gmail is unavailable in your country, then try > Fastmail/riseup/GMX etc, or even the new one OpenMbox.net > > Regards > > > On Fri, Feb 10, 2023 at 10:06 AM Digua Dong wrote: > > > hello > > new to mailing list > > > > I'm previously using zohomail.cn and some of email from mailing list are > > lost. > > I thought, it is in China, so probably because of GFW? > > And one weird thing: if I delete Notification folder, I can't receive any > > mail. > > > > Then I switched to mail.ru, but still can't get the mailing list full! > > They're not in Spam() folder, just got lost. > > > > I don't want to frequently switch mail service and wait for new mail > > and compare with marc.info to judge if it is ok. > > > > Does anyone have the same issue / is this a common thing? > > What is probably going wrong? > > > > digua > > > >
Re: Why some mail were lost, is this common?
Thanks! OpenMbox.net has the most suckless interface I've ever seen, I like it. Hope this is the last time I change the mail service. If this don't work well, I'll probably just build my own, (using my friends' domain xd) digua On Fri, Feb 10, 2023 at 04:39:13AM +, Adriel Peng wrote: > Hmm I am the person working for email delivery. > don't use mail.ru who blocks a lot of lists mail every day. > Use gmail instead. If gmail is unavailable in your country, then try > Fastmail/riseup/GMX etc, or even the new one OpenMbox.net > > Regards > > On Fri, Feb 10, 2023 at 10:06 AM Digua Dong wrote: > > hello > > new to mailing list > > > > I'm previously using zohomail.cn and some of email from mailing list are > > lost. > > I thought, it is in China, so probably because of GFW? > > And one weird thing: if I delete Notification folder, I can't receive any > > mail. > > > > Then I switched to mail.ru, but still can't get the mailing list full! > > They're not in Spam(Спам) folder, just got lost. > > > > I don't want to frequently switch mail service and wait for new mail > > and compare with marc.info to judge if it is ok. > > > > Does anyone have the same issue / is this a common thing? > > What is probably going wrong? > > > > digua
Re: Why some mail were lost, is this common?
Hmm I am the person working for email delivery. don't use mail.ru who blocks a lot of lists mail every day. Use gmail instead. If gmail is unavailable in your country, then try Fastmail/riseup/GMX etc, or even the new one OpenMbox.net Regards On Fri, Feb 10, 2023 at 10:06 AM Digua Dong wrote: > hello > new to mailing list > > I'm previously using zohomail.cn and some of email from mailing list are > lost. > I thought, it is in China, so probably because of GFW? > And one weird thing: if I delete Notification folder, I can't receive any > mail. > > Then I switched to mail.ru, but still can't get the mailing list full! > They're not in Spam(Спам) folder, just got lost. > > I don't want to frequently switch mail service and wait for new mail > and compare with marc.info to judge if it is ok. > > Does anyone have the same issue / is this a common thing? > What is probably going wrong? > > digua > >
Why some mail were lost, is this common?
hello new to mailing list I'm previously using zohomail.cn and some of email from mailing list are lost. I thought, it is in China, so probably because of GFW? And one weird thing: if I delete Notification folder, I can't receive any mail. Then I switched to mail.ru, but still can't get the mailing list full! They're not in Spam(Спам) folder, just got lost. I don't want to frequently switch mail service and wait for new mail and compare with marc.info to judge if it is ok. Does anyone have the same issue / is this a common thing? What is probably going wrong? digua
Re: Use daily(8), weekly(8), or monthly(8) but read less mail
Hallo Ibsen, > I want to use the altroot facility, but I don't want to read the mails > about the the backup succeeding and nothing else failing. > > Reading the scripts and the manual pages, I see no support for sending > the daily, weekly, or monthly mails only on failure. I also see > no support for running ROOTBACKUP outside of the daily script. > Of course I could change the scripts, but I would rather not. > Also, once I receive the mail, I don't see an easy way to classify > it as having a failure or not. > > What do you do if you want to use the altroot facility (or some > other part of the periodic system maintenance scripts) and want > to read reports only when something failed? Based on my limited understanding, the ask is for an email to be sent only when there is a failure. Failures could be in multiple places, including the very mechanism of the mail being sent. An email in the inbox represents the entire chain of maintenance having executed successfully. Lack of an email in the inbox may seem to be a successful execution, but may not always be the case. Given a multitude of machines, it is possible that reading an email a day per machine may be an onerous task. However, on the balance, it may still seem to be a better tradeoff than believing everything to be ok, when it is not. Just my two øres. > With great humility, > > Ibsen S. Ripsbusker > > Dhanyavaad, Dharma Artha Kama Moksha.
Re: Use daily(8), weekly(8), or monthly(8) but read less mail
On Sun, Dec 25, 2022 at 09:56:03AM +, Ibsen S Ripsbusker wrote: > I want to use the altroot facility, but I don't want to read the mails > about the the backup succeeding and nothing else failing. > > Reading the scripts and the manual pages, I see no support for sending > the daily, weekly, or monthly mails only on failure. I also see > no support for running ROOTBACKUP outside of the daily script. > Of course I could change the scripts, but I would rather not. > Also, once I receive the mail, I don't see an easy way to classify > it as having a failure or not. > > What do you do if you want to use the altroot facility (or some > other part of the periodic system maintenance scripts) and want > to read reports only when something failed? > > With great humility, > > Ibsen S. Ripsbusker > so these scripts used to be very chatty. then there was a decision to cut the chatter unless it was asked for (via VERBOSESTATUS). then finally to not output anything if there was nothing to report (and VERBOSESTATUS was removed, as far as i can see). so to try to answer your question: i don;t think you will get any reports of anything succeeding, and you should only get reports about actions the scripts think neccessary. if you did get any "we've done it!" messages, i suppose you'd be entitled to complain. do you? the issue for me now is that i think that somewhere we should say this. i missed VERBOSESTATUS disappearing, but i think we might want to say it. the commit message was: revision 1.29 date: 2020/10/20 22:42:29; author: danj; state: Exp; lines: +2 -19; commitid: EFsAssont5N9pxsI; Remove calls for df(1), netstat(1), and the verbose dump(1) With this change, daily(8) only sends email when something looks dubious. Consequently VERBOSESTATUS is now a no-op and may be unset. The code is trivial and riddled with choices that look like personal preferences. The old behavior can be achieved through /etc/daily.local. With schwarze@, tweak kn@, sthen@ OK schwarze@, kn@, jung@ although it's maybe true that the old behaviour can be achieved via a *.local file, there's nothing that says how. i suppose the meaning was, if you want more info, add it yourself. still i think it makes sense to say not to expect mails if everything looks ok. sth like this: Index: daily.8 === RCS file: /cvs/src/share/man/man8/daily.8,v retrieving revision 1.29 diff -u -p -r1.29 daily.8 --- daily.8 20 Oct 2020 22:42:29 - 1.29 +++ daily.8 25 Dec 2022 21:25:48 - @@ -29,7 +29,8 @@ and are shell scripts run on a periodic basis by the clock daemon, .Xr cron 8 . They take care of some basic administrative tasks. -Their output, if any, is mailed to root. +If anything looks amiss, +a report is mailed to root. .Pp .Sy Note : The scripts are all run as part of root's
Re: Use daily(8), weekly(8), or monthly(8) but read less mail
On Sun, Dec 25, 2022, Ibsen S Ripsbusker wrote: > ... want > to read reports only when something failed? Use a mail filter. #!/bin/sh # filter (in)security mails: # if it's only this: return 1 which causes the mail to be discarded egrep -v '^(Running security|Checking the /etc/master.passwd file)' "$@" -- Address is valid for this mailing list only, please do not reply to it directly, but to the list.
Re: Use daily(8), weekly(8), or monthly(8) but read less mail
On 2022-12-25, Ibsen S Ripsbusker wrote: > I want to use the altroot facility, but I don't want to read the mails > about the the backup succeeding and nothing else failing. > > Reading the scripts and the manual pages, I see no support for sending > the daily, weekly, or monthly mails only on failure. I also see > no support for running ROOTBACKUP outside of the daily script. > Of course I could change the scripts, but I would rather not. > Also, once I receive the mail, I don't see an easy way to classify > it as having a failure or not. > > What do you do if you want to use the altroot facility (or some > other part of the periodic system maintenance scripts) and want > to read reports only when something failed? Seems like it would be a useful change to make. Someone will need to change the script in order to do this, why not give it a go and send a diff if you don't want to carry a local change? -- Please keep replies on the mailing list.
Use daily(8), weekly(8), or monthly(8) but read less mail
I want to use the altroot facility, but I don't want to read the mails about the the backup succeeding and nothing else failing. Reading the scripts and the manual pages, I see no support for sending the daily, weekly, or monthly mails only on failure. I also see no support for running ROOTBACKUP outside of the daily script. Of course I could change the scripts, but I would rather not. Also, once I receive the mail, I don't see an easy way to classify it as having a failure or not. What do you do if you want to use the altroot facility (or some other part of the periodic system maintenance scripts) and want to read reports only when something failed? With great humility, Ibsen S. Ripsbusker
Re: embarrassing mail problem
On 10/5/2022 5:04 PM, Steve Fairhead wrote: I have several OpenBSD email servers, some elderly (Sendmail) and some brand-spanking new (smtpd). Recently I've noticed that some (of both kinds) are failing to deliver mail to some major UK ISPs. (Mostly domestic; business ISPs not so much.) For Sendmail, the error is "TLS handshake failed"; for smtpd, it's "Network error on destination MXs". "TLS handshake failed" usually means a TLS cipher mismatch, but maybe they're requiring a valid public certificate. You can also use testssl.sh to see what ciphers they're actually using. Check the logs and do a tcpdump of one of the failed connections. One of those should tell you directly what's wrong.
Re: embarrassing mail problem
On 2022-10-05, Steve Fairhead wrote: > I have several OpenBSD email servers, some elderly (Sendmail) and some > brand-spanking new (smtpd). Recently I've noticed that some (of both > kinds) are failing to deliver mail to some major UK ISPs. (Mostly > domestic; business ISPs not so much.) > > For Sendmail, the error is "TLS handshake failed"; for smtpd, it's > "Network error on destination MXs". Can you show some example servers that are having the problem? Has anything changed network-wise on your side that might coincide with this breaking? > I do have SPF etc setup; thought that might be it, but no. I've read > that some ISPs have closed port 25. I presume that's relevant, but I > simply don't know. Delivery to MXes is done on port 25 so nobody is closing that on the server side. Some access ISPs may filter port 25 (and if so, may or may not have a way to unblock it) but that would usually block everything on port 25, not leave some working. Shot in the dark: you could try lowering MTU as a test. -- Please keep replies on the mailing list.
Re: embarrassing mail problem
On Wed, Oct 05, 2022 at 10:04:36PM +0100, Steve Fairhead wrote: > For Sendmail, the error is "TLS handshake failed"; for smtpd, it's > "Network error on destination MXs". one "fix" would be to disable TLS for the domains in question, which at least would let the mail go through until the encryption can be set aright, perhaps with an access map entry along the lines of Try_TLS:badhost.example.com NO
Re: embarrassing mail problem
howdy Steve... on newer versions of openBSD open SMTPD legacy tls versions / ciphers are disabled by default... there is an option to allow legact tls versions ( i cant remember the option off hand but man smtpd.conf and search for tls you should find it handy enough...( this caught me out on an upgrade to 7.0 btw mxtoolbox.com has some useful tests that could help you diagnose mail flow issues... DMARC + DKIM would be worth looking at... also check the spamhaus PBL... if your isp suddenly added their subscriber ip ranges to the PBL this could negatively impact you if your mail server ip is in the ranges the ISP included in Spamhaus Policy Block List... hope this helps On Wed 5 Oct 2022, 23:07 Steve Fairhead, wrote: > I've searched and failed, and I realise I'm going to show my total > ignorance by not having found an answer (and no, I've not been keeping > up these last few years - mea culpa - demanding day-job). But - I'd be > grateful for any (gentle or otherwise) cluebats. > > I have several OpenBSD email servers, some elderly (Sendmail) and some > brand-spanking new (smtpd). Recently I've noticed that some (of both > kinds) are failing to deliver mail to some major UK ISPs. (Mostly > domestic; business ISPs not so much.) > > For Sendmail, the error is "TLS handshake failed"; for smtpd, it's > "Network error on destination MXs". > > I do have SPF etc setup; thought that might be it, but no. I've read > that some ISPs have closed port 25. I presume that's relevant, but I > simply don't know. > > As I said, all cluebats gratefully (and probably painfully) accepted. > > Steve > > -- > > -- >Steve Fairhead > email: st...@fivetrees.com > -- > >
embarrassing mail problem
I've searched and failed, and I realise I'm going to show my total ignorance by not having found an answer (and no, I've not been keeping up these last few years - mea culpa - demanding day-job). But - I'd be grateful for any (gentle or otherwise) cluebats. I have several OpenBSD email servers, some elderly (Sendmail) and some brand-spanking new (smtpd). Recently I've noticed that some (of both kinds) are failing to deliver mail to some major UK ISPs. (Mostly domestic; business ISPs not so much.) For Sendmail, the error is "TLS handshake failed"; for smtpd, it's "Network error on destination MXs". I do have SPF etc setup; thought that might be it, but no. I've read that some ISPs have closed port 25. I presume that's relevant, but I simply don't know. As I said, all cluebats gratefully (and probably painfully) accepted. Steve -- -- Steve Fairhead email: st...@fivetrees.com --
Re: Mutt cannot sent mail in OpenBsd
Hi, Thanks Stuart, I figured it out. So silly my SMTP server was indeerd serving a different cert than my imap server (DOVECOT). I used the mail.thinkerwim.org.crt instead of mail.thinkerwim.org.fullchain.pem Thank bsd team for helping me :-). See you around Bye Wim Stockman On Sat, Jul 09, 2022 at 07:47:43AM -, Stuart Henderson wrote: > On 2022-07-08, Stuart Henderson wrote: > > You are missing the intermediate certificate on the server. > > visually: > > imap - presents an intermediate cert, providing a path to the trusted root > cert > > --- > Certificate chain > 0 s:/CN=mail.thinkerwim.org >i:/C=US/O=Let's Encrypt/CN=R3 > 1 s:/C=US/O=Let's Encrypt/CN=R3 >i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 > 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 >i:/O=Digital Signature Trust Co./CN=DST Root CA X3 > --- > > smtp - doesn't > > --- > Certificate chain > 0 s:/CN=mail.thinkerwim.org >i:/C=US/O=Let's Encrypt/CN=R3 > --- > >
Re: Mutt cannot sent mail in OpenBsd
On 2022-07-08, Stuart Henderson wrote: > You are missing the intermediate certificate on the server. visually: imap - presents an intermediate cert, providing a path to the trusted root cert --- Certificate chain 0 s:/CN=mail.thinkerwim.org i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- smtp - doesn't --- Certificate chain 0 s:/CN=mail.thinkerwim.org i:/C=US/O=Let's Encrypt/CN=R3 ---
Re: Mutt cannot sent mail in OpenBsd
Indeed , OpenBSD uses LibreSSL 3.5.2 and my Artix Linux runs Openssl The LibreSSL says : Verify return code: 20 (unable to get local issuer certificate) And the OpenSSL says : Verify return code: 21 (unable to verify the first certificate) Here is the diff from both. 4,5c4,5 < 0 s:CN = mail.thinkerwim.org < i:C = US, O = Let's Encrypt, CN = R3 --- > 0 s:/CN=mail.thinkerwim.org > i:/C=US/O=Let's Encrypt/CN=R3 44,47c44,45 < subject=CN = mail.thinkerwim.org < < issuer=C = US, O = Let's Encrypt, CN = R3 < --- > subject=/CN=mail.thinkerwim.org > issuer=/C=US/O=Let's Encrypt/CN=R3 50,52c48 < Peer signing digest: SHA256 < Peer signature type: RSA-PSS < Server Temp Key: X25519, 253 bits --- > Server Temp Key: ECDH, X25519, 253 bits 54,55c50 < SSL handshake has read 2663 bytes and written 434 bytes < Verification error: unable to verify the first certificate --- > SSL handshake has read 2662 bytes and written 430 bytes 57c52 < New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 --- > New, TLSv1/SSLv3, Cipher is TLS_AES_256_GCM_SHA384 63,64c58,66 < Early data was not sent < Verify return code: 21 (unable to verify the first certificate) --- > SSL-Session: > Protocol : TLSv1.3 > Cipher : TLS_AES_256_GCM_SHA384 > Session-ID: > Session-ID-ctx: > Master-Key: > Start Time: 1657308952 > Timeout : 7200 (sec) > Verify return code: 20 (unable to get local issuer certificate) I guess I'll look into the manual of LibreSSL :-). Thanks for pointing me in the good direction. Wim Stockman On 7/8/22 20:41, Zé Loff wrote: On Fri, Jul 08, 2022 at 07:22:51PM +0200, Wim wrote: The strange thing is that the client machine and server are the same... The client's not necessarily the same. Linux might be using OpenSSL, OpenBSD is almost certainly using LibreSSL, there might be differences on the root certificates accepted by each OS, etc. Compare the output of openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 -starttls smtp and check for differences. Maybe Mut looks into the wrong place. I installed mutt from the openbsd package and using openbsd 7.1 Thanks for the help. Kind regards Wim Philipp Buehler schreef op 8 juli 2022 16:31:31 CEST: Am 08.07.2022 15:49 schrieb Dave Voutila: $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 `-starttls smtp` helps a lot. The cert is there (also on :25 ftm) and signed by LE. The rub is that the mutt client machine does not know that issuer, See openssl documentation how to do this. HTH -- pb
Re: Mutt cannot sent mail in OpenBsd
On Fri, Jul 08, 2022 at 07:22:51PM +0200, Wim wrote: > The strange thing is that the client machine and server are the same... The client's not necessarily the same. Linux might be using OpenSSL, OpenBSD is almost certainly using LibreSSL, there might be differences on the root certificates accepted by each OS, etc. Compare the output of openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 -starttls smtp and check for differences. > Maybe Mut looks into the wrong place. I installed mutt from the openbsd > package and using openbsd 7.1 > > Thanks for the help. > Kind regards > Wim > > Philipp Buehler schreef op 8 > juli 2022 16:31:31 CEST: > >Am 08.07.2022 15:49 schrieb Dave Voutila: > > > >> $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect > >> mail.thinkerwim.org:587 > > > >`-starttls smtp` helps a lot. The cert is there (also on :25 ftm) and signed > >by LE. > > > >The rub is that the mutt client machine does not know that issuer, > >See openssl documentation how to do this. > > > >HTH > >-- > >pb > > --
Re: Mutt cannot sent mail in OpenBsd
You are missing the intermediate certificate on the server. On 2022-07-08, wim wrote: > Hi everybody, > > I have this weird issue. > I can read the mails with mutt on openbsd but when I want to sent I get > this message from the mutt log: > [2022-07-08 14:33:16] mutt_send_message() Sending message... > [2022-07-08 14:33:16] raw_socket_open() Looking up mail.thinkerwim.org... > [2022-07-08 14:33:16] raw_socket_open() Connecting to > mail.thinkerwim.org... > [2022-07-08 14:33:16] ssl_negotiate() SSL failed: error:14FFF086:SSL > routines:(UNKNOWN)SSL_internal:certificate verify failed > [2022-07-08 14:33:16] smtp_open() Could not negotiate TLS connection > > From the OPENSMTPD maillog I find this > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp connected > address=46.23.92.40 host=mail.thinkerwim.org > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp > disconnected reason="io-error: handshake failed: error:1403F416:SSL > routines:ACCEPT_SR_FINISHED:sslv3 alert certificate unknown" > > > The weird thing is , if I run the same configuration of mutt on my linux > machine everything works. > > Any idea ? > > Kind Regards, > Wim Stockman > > -- Please keep replies on the mailing list.
Re: Mutt cannot sent mail in OpenBsd
The strange thing is that the client machine and server are the same... Maybe Mut looks into the wrong place. I installed mutt from the openbsd package and using openbsd 7.1 Thanks for the help. Kind regards Wim Philipp Buehler schreef op 8 juli 2022 16:31:31 CEST: >Am 08.07.2022 15:49 schrieb Dave Voutila: > >> $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect >> mail.thinkerwim.org:587 > >`-starttls smtp` helps a lot. The cert is there (also on :25 ftm) and signed >by LE. > >The rub is that the mutt client machine does not know that issuer, >See openssl documentation how to do this. > >HTH >-- >pb >
Re: Mutt cannot sent mail in OpenBsd
Am 08.07.2022 15:49 schrieb Dave Voutila: $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 `-starttls smtp` helps a lot. The cert is there (also on :25 ftm) and signed by LE. The rub is that the mutt client machine does not know that issuer, See openssl documentation how to do this. HTH -- pb
Re: Mutt cannot sent mail in OpenBsd
wim writes: > Hi everybody, > > I have this weird issue. > I can read the mails with mutt on openbsd but when I want to sent I > get this message from the mutt log: > [2022-07-08 14:33:16] mutt_send_message() Sending message... > [2022-07-08 14:33:16] raw_socket_open() Looking up mail.thinkerwim.org... > [2022-07-08 14:33:16] raw_socket_open() Connecting to > mail.thinkerwim.org... > [2022-07-08 14:33:16] ssl_negotiate() SSL failed: > error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify > failed > [2022-07-08 14:33:16] smtp_open() Could not negotiate TLS connection > > From the OPENSMTPD maillog I find this > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp > connected address=46.23.92.40 host=mail.thinkerwim.org > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp > disconnected reason="io-error: handshake failed: error:1403F416:SSL > routines:ACCEPT_SR_FINISHED:sslv3 alert certificate unknown" > > > The weird thing is , if I run the same configuration of mutt on my > linux machine everything works. > You might want to rethink your definition of "works" in this case. > Any idea ? > You sure you've configured a certificate and TLS on your mailserver? I don't see one. I a TLS listener on port :443 of mail.thinkerwim.org but that cert is for www.thinkerwim.org. $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 CONNECTED(0003) 14696819295368:error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version:/usr/src/lib/libssl/tls13_lib.c:151: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 322 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.3 Cipher: Session-ID: Session-ID-ctx: Master-Key: Start Time: 1657288016 Timeout : 7200 (sec) Verify return code: 0 (ok) ---
Mutt cannot sent mail in OpenBsd
Hi everybody, I have this weird issue. I can read the mails with mutt on openbsd but when I want to sent I get this message from the mutt log: [2022-07-08 14:33:16] mutt_send_message() Sending message... [2022-07-08 14:33:16] raw_socket_open() Looking up mail.thinkerwim.org... [2022-07-08 14:33:16] raw_socket_open() Connecting to mail.thinkerwim.org... [2022-07-08 14:33:16] ssl_negotiate() SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed [2022-07-08 14:33:16] smtp_open() Could not negotiate TLS connection From the OPENSMTPD maillog I find this Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp connected address=46.23.92.40 host=mail.thinkerwim.org Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp disconnected reason="io-error: handshake failed: error:1403F416:SSL routines:ACCEPT_SR_FINISHED:sslv3 alert certificate unknown" The weird thing is , if I run the same configuration of mutt on my linux machine everything works. Any idea ? Kind Regards, Wim Stockman
Re: Getting archived mailing list mail with majordomo
FWIW, I'm pretty sure MARC info has archives because I requested them years ago from my old email, deich...@wrench.com. 73 diana On June 24, 2022 10:43:56 AM MDT, Isaac Meerwarth wrote: >On 6/24/22 12:31, Todd C. Miller wrote: >> On Fri, 24 Jun 2022 12:18:46 -0400, Isaac Meerwarth wrote: >> >>> I've been trying to retrieve archived mailing list mail. I tried >>> sending "archive-get misc 101001" to majord...@openbsd.org but my >>> request is denied. >>> >>> I haven't found any remedies google-dorking marc.info. Ideally, I'd >>> like to download a full archive of misc and ports. Any ideas or solutions? >> This is disabled in majordomo because it doesn't act the way people >> expect. What that would do is to cause majordomo to re-send all >> the archived messages to you, one by one. That can quickly overwhelm >> the destination and get the mail server banned as a spam source. >Is there an official repository for browsing mailing list archives? marc.info >seems reputable but unofficial. >> Unfortunately, there isn't currently a way to download the >> archives in mailbox format, which is probably what you want. >Luckily, I am young and can build a nice repository myself! > >I'll be sitting pretty in 5 years :) > > >Thank you for your timely response, > >Isaac >
Re: Getting archived mailing list mail with majordomo
On Fri, 24 Jun 2022 12:43:56 -0400, Isaac Meerwarth wrote: > Is there an official repository for browsing mailing list archives? > marc.info seems reputable but unofficial. > > Unfortunately, there isn't currently a way to download the > > archives in mailbox format, which is probably what you want. > Luckily, I am young and can build a nice repository myself! You can access the archives from lists.openbsd.org as long as you are subscribed to the list (and thus have a password). https://lists.openbsd.org/cgi-bin/mj_wwwusr?user===lists-long-full=misc - todd
Re: Getting archived mailing list mail with majordomo
On 6/24/22 12:31, Todd C. Miller wrote: On Fri, 24 Jun 2022 12:18:46 -0400, Isaac Meerwarth wrote: I've been trying to retrieve archived mailing list mail. I tried sending "archive-get misc 101001" to majord...@openbsd.org but my request is denied. I haven't found any remedies google-dorking marc.info. Ideally, I'd like to download a full archive of misc and ports. Any ideas or solutions? This is disabled in majordomo because it doesn't act the way people expect. What that would do is to cause majordomo to re-send all the archived messages to you, one by one. That can quickly overwhelm the destination and get the mail server banned as a spam source. Is there an official repository for browsing mailing list archives? marc.info seems reputable but unofficial. Unfortunately, there isn't currently a way to download the archives in mailbox format, which is probably what you want. Luckily, I am young and can build a nice repository myself! I'll be sitting pretty in 5 years :) Thank you for your timely response, Isaac
Re: Getting archived mailing list mail with majordomo
On Fri, 24 Jun 2022 12:18:46 -0400, Isaac Meerwarth wrote: > I've been trying to retrieve archived mailing list mail. I tried > sending "archive-get misc 101001" to majord...@openbsd.org but my > request is denied. > > I haven't found any remedies google-dorking marc.info. Ideally, I'd > like to download a full archive of misc and ports. Any ideas or solutions? This is disabled in majordomo because it doesn't act the way people expect. What that would do is to cause majordomo to re-send all the archived messages to you, one by one. That can quickly overwhelm the destination and get the mail server banned as a spam source. Unfortunately, there isn't currently a way to download the archives in mailbox format, which is probably what you want. - todd
Getting archived mailing list mail with majordomo
Hello misc, I've been trying to retrieve archived mailing list mail. I tried sending "archive-get misc 101001" to majord...@openbsd.org but my request is denied. I haven't found any remedies google-dorking marc.info. Ideally, I'd like to download a full archive of misc and ports. Any ideas or solutions? Thanks, Isaac
Re: mutt fetch-mail ssl error
On Wed, May 25, 2022 at 12:03:00PM -, Stuart Henderson wrote: > On 2022-05-22, Avon Robertson wrote: > > The libcrypto build and install as outlined above by Theo was completed > > without error a few minutes ago on the Dell M6600. It was then rebooted > > and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. > > > > Sadly the attempt failed and mutt's error-history command displayed the > > same error as above. > > I've just tested with the current snapshot: > > $ TZ=UTC ls -l /usr/lib/libssl.so.52.0 /usr/local/bin/mutt > -r--r--r-- 1 root bin 1509824 May 25 06:51 /usr/lib/libssl.so.52.0 > -rwxr-xr-x 1 root bin 1318616 May 24 02:11 /usr/local/bin/mutt > > Testing with pop3.xtra.co.nz, I don't have an account but a bogus > username is good enough to check that TLS works, so I added this to > the default muttrc > > set pop_host=pops://t...@pop3.xtra.co.nz/ > > Run mutt and press G - no TLS failure. > > Thanks for your response Stuart. Last night I downloaded and reinstalled, bsd.rd 'i' not 'u', the then latest -current snapshot from mirror.aarnet.edu.au/pub/OpenBSD, and reinstalled the packages that I wanted/needed on the M6600 laptop. Then coincidently, invoking your TZ... ls -l command above outputs the same information. Changing the set_host=... line in my ~/.muttrc file however, fails and the error-history command displays the same error information shown in several of the earlier posts in this thread. Time permitting, in the next couple of days I will put the latest snapshot and packages on a 'long in the tooth' i3 processor host and see if it too, is still reporting the same error. I will also attempt tonight to access my xtra.co.nz emails using webmail with firefox. This host on which mutt still works, is way overdue for an update. This will not be performed until my other hosts can access my emails. It's kernel version is 7.1 (GENERIC.MP) #454. -- aer
Re: mutt fetch-mail ssl error
On 2022-05-22, Avon Robertson wrote: > The libcrypto build and install as outlined above by Theo was completed > without error a few minutes ago on the Dell M6600. It was then rebooted > and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. > > Sadly the attempt failed and mutt's error-history command displayed the > same error as above. I've just tested with the current snapshot: $ TZ=UTC ls -l /usr/lib/libssl.so.52.0 /usr/local/bin/mutt -r--r--r-- 1 root bin 1509824 May 25 06:51 /usr/lib/libssl.so.52.0 -rwxr-xr-x 1 root bin 1318616 May 24 02:11 /usr/local/bin/mutt Testing with pop3.xtra.co.nz, I don't have an account but a bogus username is good enough to check that TLS works, so I added this to the default muttrc set pop_host=pops://t...@pop3.xtra.co.nz/ Run mutt and press G - no TLS failure.
Re: mutt fetch-mail ssl error
On Tue, May 24, 2022 at 07:45:03PM +0200, Maik wrote: > On Sun, May 22, 2022 at 09:53:29PM +1200, Avon Robertson wrote: > > On Sun, May 22, 2022 at 10:15:35AM +1200, Avon Robertson wrote: > > > On Fri, May 20, 2022 at 10:25:39PM +1200, Avon Robertson wrote: > > > > On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > > > > > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > > > > > I have been unable to fetch mail with mutt on this host using > > > > > > either the > > > > > > currently installed snapshot and mutt package, or the snapshot and > > > > > > mutt > > > > > > package that had been installed 2-3 days previously. > > > > > > > > > > > > I have been able to send mail using mutt in conjuction with msmtp > > > > > > from > > > > > > this host. > > > > > > > > > > > > mutt's error-history command displays > > > > > > > > > > > > Reading /home/aer/var/mail/inbox... > > > > > > Reading /home/aer/var/mail/inbox... 0 > > > > > > Looking up pop3.xtra.co.nz... > > > > > > Connecting to pop3.xtra.co.nz... > > > > > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > > > > > +verify failed > > > > > > Error connecting to server: pop3.xtra.co.nz > > > > > > > > > > There is a good chance that this is a bug I introduced by adding a > > > > > more > > > > > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now > > > > > fail > > > > > if passed an uninitialized pointer. This bug should be fixed via > > > > > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and > > > > > relax > > > > > the check again. > > > > > > > > > > X509_verify_cert() > > > > > x509_verify() > > > > > x509_verify_cert_hostname() > > > > >X509_check_host() > > > > > do_x509_check() > > > > > do_check_string() > > > > > ASN1_STRING_to_UTF8() > > > > > > > > > > If this is the problem, you can fix this by checking out very current > > > > > sources and rebuilding libcrypto > > > > > > > > > > cd /usr/src/lib/libcrypto > > > > > make obj > > > > > doas make includes > > > > > make > > > > > doas make install > > > > > > > > > > or you can wait for a new snapshot including this fix and try again. > > > > > > > > Thank you for your response Theo. It past my bed time tonight. Tomorrow > > > > I will do what you have suggested above. > > > > > > > > Regards > > > > -- > > > > aer > > > > > > > > > > The latest snapshot from mirror.aaarnet.edu.au was installed near > > > midday the following day on the affected host and all packages were > > > updated. The host was then powered down. Unfortunately, when it was > > > later powered on I found that the power supply had died and that I would > > > have to buy a replacement. > > > > > > So, this morning one day later, I installed the latest snapshot from > > > the above mirror on a Dell M6600 laptop and updated all installed > > > packages. The kernel and mutt versions are now: > > > > > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #537: Fri May 20 22:45:40 > > > MDT 2022 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > drwxr-xr-x 2 root wheel 512 May 21 18:41 mutt-2.2.5v3-gpgme-sasl > > > > > > Alas, the same mutt error occurs as shown above. Later today if time > > > permits, else tomorrow; I will build libcrypto on the laptop and see if > > > this fixes the error. > > > > > > Regards > > > -- > > > aer > > > > > > > The libcrypto build and install as outlined above by Theo was completed > > without error a few minutes ago on the Dell M6600. It was then rebooted > > and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. > > > > Sadly the attempt failed and mutt's error-history command displayed the > > same error as above. > > > > So perhaps mutt's fetch-mail error is unrelated to libcrypto's recent > > bug. > > > > Any hints or advice to resolve this issue? > > > > Regards > > -- > > aer > > > > I had a similiar problem recently (though I don't remember the error > messages so not sure if this will help), in my case I had mutt installed > without SASL support, you can check with mutt -v | grep sasl and if it > shows "-sasl" in the output (second line) reinstall a mutt-flavor that > includes sasl Thank you for responding Maik. A few lines above you will see that the installed mutt package is: mutt-2.2.5v3-gpgme-sasl. The output of 'mutt -v' includes: '--with-sasl=/usr/local', '--enable-gpme', and '--with-ssl'. This matter is still unresolved unfortunatly. -- aer
Re: mutt fetch-mail ssl error
On Sun, May 22, 2022 at 09:53:29PM +1200, Avon Robertson wrote: > On Sun, May 22, 2022 at 10:15:35AM +1200, Avon Robertson wrote: > > On Fri, May 20, 2022 at 10:25:39PM +1200, Avon Robertson wrote: > > > On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > > > > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > > > > I have been unable to fetch mail with mutt on this host using either > > > > > the > > > > > currently installed snapshot and mutt package, or the snapshot and > > > > > mutt > > > > > package that had been installed 2-3 days previously. > > > > > > > > > > I have been able to send mail using mutt in conjuction with msmtp from > > > > > this host. > > > > > > > > > > mutt's error-history command displays > > > > > > > > > > Reading /home/aer/var/mail/inbox... > > > > > Reading /home/aer/var/mail/inbox... 0 > > > > > Looking up pop3.xtra.co.nz... > > > > > Connecting to pop3.xtra.co.nz... > > > > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > > > > +verify failed > > > > > Error connecting to server: pop3.xtra.co.nz > > > > > > > > There is a good chance that this is a bug I introduced by adding a more > > > > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail > > > > if passed an uninitialized pointer. This bug should be fixed via > > > > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax > > > > the check again. > > > > > > > > X509_verify_cert() > > > > x509_verify() > > > > x509_verify_cert_hostname() > > > >X509_check_host() > > > > do_x509_check() > > > > do_check_string() > > > > ASN1_STRING_to_UTF8() > > > > > > > > If this is the problem, you can fix this by checking out very current > > > > sources and rebuilding libcrypto > > > > > > > > cd /usr/src/lib/libcrypto > > > > make obj > > > > doas make includes > > > > make > > > > doas make install > > > > > > > > or you can wait for a new snapshot including this fix and try again. > > > > > > Thank you for your response Theo. It past my bed time tonight. Tomorrow > > > I will do what you have suggested above. > > > > > > Regards > > > -- > > > aer > > > > > > > The latest snapshot from mirror.aaarnet.edu.au was installed near > > midday the following day on the affected host and all packages were > > updated. The host was then powered down. Unfortunately, when it was > > later powered on I found that the power supply had died and that I would > > have to buy a replacement. > > > > So, this morning one day later, I installed the latest snapshot from > > the above mirror on a Dell M6600 laptop and updated all installed > > packages. The kernel and mutt versions are now: > > > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #537: Fri May 20 22:45:40 MDT > > 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > drwxr-xr-x 2 root wheel 512 May 21 18:41 mutt-2.2.5v3-gpgme-sasl > > > > Alas, the same mutt error occurs as shown above. Later today if time > > permits, else tomorrow; I will build libcrypto on the laptop and see if > > this fixes the error. > > > > Regards > > -- > > aer > > > > The libcrypto build and install as outlined above by Theo was completed > without error a few minutes ago on the Dell M6600. It was then rebooted > and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. > > Sadly the attempt failed and mutt's error-history command displayed the > same error as above. > > So perhaps mutt's fetch-mail error is unrelated to libcrypto's recent > bug. > > Any hints or advice to resolve this issue? > > Regards > -- > aer > I had a similiar problem recently (though I don't remember the error messages so not sure if this will help), in my case I had mutt installed without SASL support, you can check with mutt -v | grep sasl and if it shows "-sasl" in the output (second line) reinstall a mutt-flavor that includes sasl
Re: mutt fetch-mail ssl error
On Sun, May 22, 2022 at 10:15:35AM +1200, Avon Robertson wrote: > On Fri, May 20, 2022 at 10:25:39PM +1200, Avon Robertson wrote: > > On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > > > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > > > I have been unable to fetch mail with mutt on this host using either the > > > > currently installed snapshot and mutt package, or the snapshot and mutt > > > > package that had been installed 2-3 days previously. > > > > > > > > I have been able to send mail using mutt in conjuction with msmtp from > > > > this host. > > > > > > > > mutt's error-history command displays > > > > > > > > Reading /home/aer/var/mail/inbox... > > > > Reading /home/aer/var/mail/inbox... 0 > > > > Looking up pop3.xtra.co.nz... > > > > Connecting to pop3.xtra.co.nz... > > > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > > > +verify failed > > > > Error connecting to server: pop3.xtra.co.nz > > > > > > There is a good chance that this is a bug I introduced by adding a more > > > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail > > > if passed an uninitialized pointer. This bug should be fixed via > > > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax > > > the check again. > > > > > > X509_verify_cert() > > > x509_verify() > > > x509_verify_cert_hostname() > > >X509_check_host() > > > do_x509_check() > > > do_check_string() > > > ASN1_STRING_to_UTF8() > > > > > > If this is the problem, you can fix this by checking out very current > > > sources and rebuilding libcrypto > > > > > > cd /usr/src/lib/libcrypto > > > make obj > > > doas make includes > > > make > > > doas make install > > > > > > or you can wait for a new snapshot including this fix and try again. > > > > Thank you for your response Theo. It past my bed time tonight. Tomorrow > > I will do what you have suggested above. > > > > Regards > > -- > > aer > > > > The latest snapshot from mirror.aaarnet.edu.au was installed near > midday the following day on the affected host and all packages were > updated. The host was then powered down. Unfortunately, when it was > later powered on I found that the power supply had died and that I would > have to buy a replacement. > > So, this morning one day later, I installed the latest snapshot from > the above mirror on a Dell M6600 laptop and updated all installed > packages. The kernel and mutt versions are now: > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #537: Fri May 20 22:45:40 MDT > 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > drwxr-xr-x 2 root wheel 512 May 21 18:41 mutt-2.2.5v3-gpgme-sasl > > Alas, the same mutt error occurs as shown above. Later today if time > permits, else tomorrow; I will build libcrypto on the laptop and see if > this fixes the error. > > Regards > -- > aer > The libcrypto build and install as outlined above by Theo was completed without error a few minutes ago on the Dell M6600. It was then rebooted and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. Sadly the attempt failed and mutt's error-history command displayed the same error as above. So perhaps mutt's fetch-mail error is unrelated to libcrypto's recent bug. Any hints or advice to resolve this issue? Regards -- aer
Re: mutt fetch-mail ssl error
On Fri, May 20, 2022 at 10:25:39PM +1200, Avon Robertson wrote: > On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > > I have been unable to fetch mail with mutt on this host using either the > > > currently installed snapshot and mutt package, or the snapshot and mutt > > > package that had been installed 2-3 days previously. > > > > > > I have been able to send mail using mutt in conjuction with msmtp from > > > this host. > > > > > > mutt's error-history command displays > > > > > > Reading /home/aer/var/mail/inbox... > > > Reading /home/aer/var/mail/inbox... 0 > > > Looking up pop3.xtra.co.nz... > > > Connecting to pop3.xtra.co.nz... > > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > > +verify failed > > > Error connecting to server: pop3.xtra.co.nz > > > > There is a good chance that this is a bug I introduced by adding a more > > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail > > if passed an uninitialized pointer. This bug should be fixed via > > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax > > the check again. > > > > X509_verify_cert() > > x509_verify() > > x509_verify_cert_hostname() > >X509_check_host() > > do_x509_check() > > do_check_string() > > ASN1_STRING_to_UTF8() > > > > If this is the problem, you can fix this by checking out very current > > sources and rebuilding libcrypto > > > > cd /usr/src/lib/libcrypto > > make obj > > doas make includes > > make > > doas make install > > > > or you can wait for a new snapshot including this fix and try again. > > Thank you for your response Theo. It past my bed time tonight. Tomorrow > I will do what you have suggested above. > > Regards > -- > aer > The latest snapshot from mirror.aaarnet.edu.au was installed near midday the following day on the affected host and all packages were updated. The host was then powered down. Unfortunately, when it was later powered on I found that the power supply had died and that I would have to buy a replacement. So, this morning one day later, I installed the latest snapshot from the above mirror on a Dell M6600 laptop and updated all installed packages. The kernel and mutt versions are now: kern.version=OpenBSD 7.1-current (GENERIC.MP) #537: Fri May 20 22:45:40 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP drwxr-xr-x 2 root wheel 512 May 21 18:41 mutt-2.2.5v3-gpgme-sasl Alas, the same mutt error occurs as shown above. Later today if time permits, else tomorrow; I will build libcrypto on the laptop and see if this fixes the error. Regards -- aer
Re: mutt fetch-mail ssl error
Am Fri, 20 May 2022 15:10:08 +0100 schrieb Stuart Henderson : > On 2022/05/20 22:18, Avon Robertson wrote: > > Thank you for your response Stuart. Alas your suggestion to try the > > binary from the working host does not work. I have pasted a log of > > my actions below. I will try Theo's fix tomorrow. > > Hopefully there will be a snapshot by then so you can just update to > it - given the tests you've done thus far, it's clearly due to a > change in libressl, and testing with nc shows that it's not a general > problem rather something with how mutt interface with it, so there's > a good chance that will fix the issue. Updating to the newest snapshot fixed the problem for me with prosody, thank you! kern.version=OpenBSD 7.1-current (GENERIC) #515: Fri May 20 22:36:43 MDT 2022 > > $ fgrep -e 995 ~/.muttrc > > set pop_host="pops://avo...@pop3.xtra.co.nz:995" > > > > $ nc -vvc pop3.xtra.co.nz 995 > > Connection to pop3.xtra.co.nz (210.55.143.37) 995 port [tcp/pop3s] > > succeeded! > > TLS handshake negotiated TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 with > > host pop3.xtra.co.nz > > Peer name: pop3.xtra.co.nz > > Subject: /C=NZ/L=Auckland/O=Spark New Zealand Limited/OU=Spark > > Connect/CN=pop3.xtra.co.nz > > Issuer: /C=US/O=Entrust, Inc./OU=See > > www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for > > authorized use only/CN=Entrust Certification Authority - L1K > > Valid From: Thu Jul 22 12:41:29 2021 > > Valid Until: Wed Aug 17 12:41:29 2022 > > Cert Hash: > > SHA256:ec5b8868a45006e3b185fe01a918b88598d5ac113822985a988c64fb395537ca > > OCSP URL: http://ocsp.entrust.net > > +OK pop3.xtra.co.nz POP3 server ready > > ^C > > > > On working mail host: > > $ rsync -v /usr/local/bin/mutt errhost.xyz.abcd:/home/aer > > > > On errhost: > > # chown root:bin /home/aer/mutt > > $ cd > > $ ./mutt > > > > Does not work and mutt's error-history command reports the same > > error. > > > > Regards > > -- > > aer > > > -- greetings, Florian Viehweger
Re: mutt fetch-mail ssl error
On 2022/05/20 22:18, Avon Robertson wrote: > Thank you for your response Stuart. Alas your suggestion to try the > binary from the working host does not work. I have pasted a log of my > actions below. I will try Theo's fix tomorrow. Hopefully there will be a snapshot by then so you can just update to it - given the tests you've done thus far, it's clearly due to a change in libressl, and testing with nc shows that it's not a general problem rather something with how mutt interface with it, so there's a good chance that will fix the issue. > $ fgrep -e 995 ~/.muttrc > set pop_host="pops://avo...@pop3.xtra.co.nz:995" > > $ nc -vvc pop3.xtra.co.nz 995 > Connection to pop3.xtra.co.nz (210.55.143.37) 995 port [tcp/pop3s] > succeeded! > TLS handshake negotiated TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 with host > pop3.xtra.co.nz > Peer name: pop3.xtra.co.nz > Subject: /C=NZ/L=Auckland/O=Spark New Zealand Limited/OU=Spark > Connect/CN=pop3.xtra.co.nz > Issuer: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) > 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification > Authority - L1K > Valid From: Thu Jul 22 12:41:29 2021 > Valid Until: Wed Aug 17 12:41:29 2022 > Cert Hash: > SHA256:ec5b8868a45006e3b185fe01a918b88598d5ac113822985a988c64fb395537ca > OCSP URL: http://ocsp.entrust.net > +OK pop3.xtra.co.nz POP3 server ready > ^C > > On working mail host: > $ rsync -v /usr/local/bin/mutt errhost.xyz.abcd:/home/aer > > On errhost: > # chown root:bin /home/aer/mutt > $ cd > $ ./mutt > > Does not work and mutt's error-history command reports the same error. > > Regards > -- > aer >
Re: mutt fetch-mail ssl error
On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > I have been unable to fetch mail with mutt on this host using either the > > currently installed snapshot and mutt package, or the snapshot and mutt > > package that had been installed 2-3 days previously. > > > > I have been able to send mail using mutt in conjuction with msmtp from > > this host. > > > > mutt's error-history command displays > > > > Reading /home/aer/var/mail/inbox... > > Reading /home/aer/var/mail/inbox... 0 > > Looking up pop3.xtra.co.nz... > > Connecting to pop3.xtra.co.nz... > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > +verify failed > > Error connecting to server: pop3.xtra.co.nz > > There is a good chance that this is a bug I introduced by adding a more > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail > if passed an uninitialized pointer. This bug should be fixed via > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax > the check again. > > X509_verify_cert() > x509_verify() > x509_verify_cert_hostname() >X509_check_host() > do_x509_check() > do_check_string() > ASN1_STRING_to_UTF8() > > If this is the problem, you can fix this by checking out very current > sources and rebuilding libcrypto > > cd /usr/src/lib/libcrypto > make obj > doas make includes > make > doas make install > > or you can wait for a new snapshot including this fix and try again. Thank you for your response Theo. It past my bed time tonight. Tomorrow I will do what you have suggested above. Regards -- aer
Re: mutt fetch-mail ssl error
On Fri, May 20, 2022 at 08:32:38AM -, Stuart Henderson wrote: > On 2022-05-20, Avon Robertson wrote: > > I have been unable to fetch mail with mutt on this host using either the > > currently installed snapshot and mutt package, or the snapshot and mutt > > package that had been installed 2-3 days previously. > > > > I have been able to send mail using mutt in conjuction with msmtp from > > this host. > > > > mutt's error-history command displays > > > > Reading /home/aer/var/mail/inbox... > > Reading /home/aer/var/mail/inbox... 0 > > Looking up pop3.xtra.co.nz... > > Connecting to pop3.xtra.co.nz... > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > +verify failed > > Error connecting to server: pop3.xtra.co.nz > > I assume this is pop3s on port 995? > What do you get from "nc -vvc pop3.xtra.co.nz 995"? > > > The below snapshot was installed yesterday and all packages were updated > > immediately afterwards such that mutt's version is now 2.2.5. > > > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT > > 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Another amd64 host that I have with OpenBSD 7.1 (GENERIC.MP) #454 and > > mutt 2.2.2 installed, fetches and sends mail without error using the > > same set of mutt configuration files. > > Try copying the mutt binary from the working system (don't overwrite the file > from the installed package, just put it in ~ and run it from there) - does > that > work or not? > > Thank you for your response Stuart. Alas your suggestion to try the binary from the working host does not work. I have pasted a log of my actions below. I will try Theo's fix tomorrow. $ fgrep -e 995 ~/.muttrc set pop_host="pops://avo...@pop3.xtra.co.nz:995" $ nc -vvc pop3.xtra.co.nz 995 Connection to pop3.xtra.co.nz (210.55.143.37) 995 port [tcp/pop3s] succeeded! TLS handshake negotiated TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 with host pop3.xtra.co.nz Peer name: pop3.xtra.co.nz Subject: /C=NZ/L=Auckland/O=Spark New Zealand Limited/OU=Spark Connect/CN=pop3.xtra.co.nz Issuer: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K Valid From: Thu Jul 22 12:41:29 2021 Valid Until: Wed Aug 17 12:41:29 2022 Cert Hash: SHA256:ec5b8868a45006e3b185fe01a918b88598d5ac113822985a988c64fb395537ca OCSP URL: http://ocsp.entrust.net +OK pop3.xtra.co.nz POP3 server ready ^C On working mail host: $ rsync -v /usr/local/bin/mutt errhost.xyz.abcd:/home/aer On errhost: # chown root:bin /home/aer/mutt $ cd $ ./mutt Does not work and mutt's error-history command reports the same error. Regards -- aer
Re: mutt fetch-mail ssl error
Am Fri, 20 May 2022 10:47:12 +0200 schrieb Theo Buehler : > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > I have been unable to fetch mail with mutt on this host using > > either the currently installed snapshot and mutt package, or the > > snapshot and mutt package that had been installed 2-3 days > > previously. > > > > I have been able to send mail using mutt in conjuction with msmtp > > from this host. > > > > mutt's error-history command displays > > > > Reading /home/aer/var/mail/inbox... > > Reading /home/aer/var/mail/inbox... 0 > > Looking up pop3.xtra.co.nz... > > Connecting to pop3.xtra.co.nz... > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > +verify failed > > Error connecting to server: pop3.xtra.co.nz > > There is a good chance that this is a bug I introduced by adding a > more stringent check when rewriting ASN1_STRING_to_UTF8(). This can > now fail if passed an uninitialized pointer. This bug should be fixed > via x509_utl.c r1.3 and a_string.c r1.11 which add initialization and > relax the check again. > > X509_verify_cert() > x509_verify() > x509_verify_cert_hostname() >X509_check_host() > do_x509_check() > do_check_string() > ASN1_STRING_to_UTF8() > > If this is the problem, you can fix this by checking out very current > sources and rebuilding libcrypto > > cd /usr/src/lib/libcrypto > make obj > doas make includes > make > doas make install > > or you can wait for a new snapshot including this fix and try again. > Thanks for the note. I also saw some x509 errors when prosody would not start after updating the system yesterday. potato# prosodyctl /usr/local/bin/lua53: /usr/local/lib/prosody/util/x509.lua:270: bad argument #1 to 'nameprep' (string expected, got nil) stack traceback: [C]: in upvalue 'nameprep' /usr/local/lib/prosody/util/x509.lua:270: in function 'util.x509.get_identities' /usr/local/lib/prosody/core/certmanager.lua:131: in function 'core.certmanager.index_certs' /usr/local/lib/prosody/core/certmanager.lua:175: in function 'core.certmanager.find_host_cert' /usr/local/lib/prosody/core/certmanager.lua:330: in function 'core.certmanager.create_context' /usr/local/lib/prosody/util/startup.lua:394: in function 'util.startup.init_http_client' /usr/local/lib/prosody/util/startup.lua:663: in function 'util.startup.prosodyctl' /usr/local/sbin/prosodyctl:48: in main chunk [C]: in ? -- greetings, Florian Viehweger
Re: mutt fetch-mail ssl error
On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > I have been unable to fetch mail with mutt on this host using either the > currently installed snapshot and mutt package, or the snapshot and mutt > package that had been installed 2-3 days previously. > > I have been able to send mail using mutt in conjuction with msmtp from > this host. > > mutt's error-history command displays > > Reading /home/aer/var/mail/inbox... > Reading /home/aer/var/mail/inbox... 0 > Looking up pop3.xtra.co.nz... > Connecting to pop3.xtra.co.nz... > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > +verify failed > Error connecting to server: pop3.xtra.co.nz There is a good chance that this is a bug I introduced by adding a more stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail if passed an uninitialized pointer. This bug should be fixed via x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax the check again. X509_verify_cert() x509_verify() x509_verify_cert_hostname() X509_check_host() do_x509_check() do_check_string() ASN1_STRING_to_UTF8() If this is the problem, you can fix this by checking out very current sources and rebuilding libcrypto cd /usr/src/lib/libcrypto make obj doas make includes make doas make install or you can wait for a new snapshot including this fix and try again.
Re: mutt fetch-mail ssl error
On 2022-05-20, Avon Robertson wrote: > I have been unable to fetch mail with mutt on this host using either the > currently installed snapshot and mutt package, or the snapshot and mutt > package that had been installed 2-3 days previously. > > I have been able to send mail using mutt in conjuction with msmtp from > this host. > > mutt's error-history command displays > > Reading /home/aer/var/mail/inbox... > Reading /home/aer/var/mail/inbox... 0 > Looking up pop3.xtra.co.nz... > Connecting to pop3.xtra.co.nz... > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > +verify failed > Error connecting to server: pop3.xtra.co.nz I assume this is pop3s on port 995? What do you get from "nc -vvc pop3.xtra.co.nz 995"? > The below snapshot was installed yesterday and all packages were updated > immediately afterwards such that mutt's version is now 2.2.5. > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT > 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Another amd64 host that I have with OpenBSD 7.1 (GENERIC.MP) #454 and > mutt 2.2.2 installed, fetches and sends mail without error using the > same set of mutt configuration files. Try copying the mutt binary from the working system (don't overwrite the file from the installed package, just put it in ~ and run it from there) - does that work or not?
mutt fetch-mail ssl error
I have been unable to fetch mail with mutt on this host using either the currently installed snapshot and mutt package, or the snapshot and mutt package that had been installed 2-3 days previously. I have been able to send mail using mutt in conjuction with msmtp from this host. mutt's error-history command displays Reading /home/aer/var/mail/inbox... Reading /home/aer/var/mail/inbox... 0 Looking up pop3.xtra.co.nz... Connecting to pop3.xtra.co.nz... SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate +verify failed Error connecting to server: pop3.xtra.co.nz The below snapshot was installed yesterday and all packages were updated immediately afterwards such that mutt's version is now 2.2.5. kern.version=OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19 07:38:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Another amd64 host that I have with OpenBSD 7.1 (GENERIC.MP) #454 and mutt 2.2.2 installed, fetches and sends mail without error using the same set of mutt configuration files. Am I able to rectify the above error, and if so how? Regards -- aer
Re: rspamd and empty "mail from" header
18.02.2022 14:26, Claus Assmann пишет: On Fri, Feb 18, 2022, kasak wrote: But, is this correct behavior of "mail from" header? Maybe the header What is a ``"mail from" header''? Do you mean the mail header From: or are you referring to the SMTP MAIL command MAIL From: should have "<>" in it? You can check the fine RFCs (e.g., 5322 for headers, 5321 for SMTP) -- AFAICT an empty address is not valid for the "From:" header and certainly not for the MAIL command. I am referring to smtp "mail from" command. As I see in rfc5321: A MAIL command with a null reverse-path appears as follows: MAIL FROM:<> And Vsevolod, developer of rspamd, mentioned that mails coming to rspamd from opensmtpd appear to have no "<>" Honestly, I'm far from developing and I can't understand where the brackets gone. I just want to help solve problem that maybe some other users can face.
Re: rspamd and empty "mail from" header
On 2022-02-18, kasak wrote: > Hello misc! I have mailed this message at m...@opensmtpd.org at first, > but nobody answered, maybe someone help here? > > I have a question about opensmtpd and rspamd. > I'm using opensmtp and rspamd as a relay server with spam checking. > The spam check is done with help of opensmtpd-filter-rspamd. > The os is OpenBSD 7.0 > > I have noticed, that all DSN messages coming to or from internal mail > server, are marked as spam, because rspamd adds BROKEN HEADERS for > this messages. > First of all, I tried to research this issue but with no luck, i've > created this issue on rspamd github repo > https://github.com/rspamd/rspamd/issues/3983 > And we found that messages with "broken headers" have empty "mail > from" header, where rspamd expect it as "<>" > > The patch to workaround this was added to rspamd side. > But, is this correct behavior of "mail from" header? Maybe the header > should have "<>" in it? If I understand correctly this relates to the protocol used when feeding the message to rspamd, i.e. the part which is handled only by opensmtpd-filter-rspamd and rspamd, rather than something in SMTP. https://rspamd.com/doc/architecture/protocol.html#http-headers just says "Defines SMTP mail from command data" and isn't clear whether the angle brackets should be included. So I would say that it's under-specified in rspamd docs. In that case I would think "correct behaviour" is whatever rspamd expects.. -- Please keep replies on the mailing list.
Re: rspamd and empty "mail from" header
On Fri, Feb 18, 2022, kasak wrote: > But, is this correct behavior of "mail from" header? Maybe the header What is a ``"mail from" header''? Do you mean the mail header From: or are you referring to the SMTP MAIL command MAIL From: > should have "<>" in it? You can check the fine RFCs (e.g., 5322 for headers, 5321 for SMTP) -- AFAICT an empty address is not valid for the "From:" header and certainly not for the MAIL command. -- Address is valid for this mailing list only, please do not reply to it directly, but to the list.
rspamd and empty "mail from" header
Hello misc! I have mailed this message at m...@opensmtpd.org at first, but nobody answered, maybe someone help here? I have a question about opensmtpd and rspamd. I'm using opensmtp and rspamd as a relay server with spam checking. The spam check is done with help of opensmtpd-filter-rspamd. The os is OpenBSD 7.0 I have noticed, that all DSN messages coming to or from internal mail server, are marked as spam, because rspamd adds BROKEN HEADERS for this messages. First of all, I tried to research this issue but with no luck, i've created this issue on rspamd github repo https://github.com/rspamd/rspamd/issues/3983 And we found that messages with "broken headers" have empty "mail from" header, where rspamd expect it as "<>" The patch to workaround this was added to rspamd side. But, is this correct behavior of "mail from" header? Maybe the header should have "<>" in it?
Re: Limit Mail Submission to inet4
On Thu, 18 Nov 2021, Simon Hoffmann wrote: Why? Why not fix the IPv6 issue? Our servers deliver to gmail over IPv6 with no issues. Hmm, thats interesting. The last time i googled it said that its a known issue with gmail and one should use IPv4. Also, the GMail help No problems sending IPv6 to gmail here either (using he.net).
Re: Limit Mail Submission to inet4
On 2021-11-18, Simon Hoffmann wrote: > --TB36FDmn/VVEgNH/ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: 7bit > >> On Thu, Nov 18, 2021 at 10:55:00AM +0100, Simon Hoffmann wrote: >> > > >> > > >> > > >GMail still wont accept my IPv6 submitted mails. >> > > >> > > Are you using ipv6 connectivity over tunnel from tunnelbroker.net? >> > >> > Nope. My relays have "real" IPv6 /64 networks assigned to their interfaces >> > natively. >> > >> > However, I'd still like to only use IPv4 when sending messages. >> >> Why? Why not fix the IPv6 issue? Our servers deliver to gmail over IPv6 >> with >> no issues. Google certainly seem much more stringent about what mail they'll accept over v6. Several MTA now have a way to disable v6 / drop records that was *specifically* added to get around problems delivering to Google. > Hmm, thats interesting. The last time i googled it said that its a known > issue with > gmail and one should use IPv4. Also, the GMail help and the error message > were all to > no use. > > I will try sending via IPv6 later today and report back. > > If you like, you can lookup DNS recors for mxbackup.hetzner.hoffbox.net > Should be correct. PTR has the same name as A/AAAa, A and are present... Hetzner address space is not likely to have the best IP reputation on mail receivers.. -- Please keep replies on the mailing list.
Re: Limit Mail Submission to inet4
> On Thu, Nov 18, 2021 at 10:55:00AM +0100, Simon Hoffmann wrote: > > > > > > > > > >GMail still wont accept my IPv6 submitted mails. > > > > > > Are you using ipv6 connectivity over tunnel from tunnelbroker.net? > > > > Nope. My relays have "real" IPv6 /64 networks assigned to their interfaces > > natively. > > > > However, I'd still like to only use IPv4 when sending messages. > > Why? Why not fix the IPv6 issue? Our servers deliver to gmail over IPv6 with > no issues. Hmm, thats interesting. The last time i googled it said that its a known issue with gmail and one should use IPv4. Also, the GMail help and the error message were all to no use. I will try sending via IPv6 later today and report back. If you like, you can lookup DNS recors for mxbackup.hetzner.hoffbox.net Should be correct. PTR has the same name as A/AAAa, A and are present... > > > Suggestions? > > Set a fixed IPv4 source address using the src parameter in the action > directive > of your smtpd.conf. Yeah, thats a good idea, thanks! Will be my fallback if i cant get v6 to work. signature.asc Description: PGP signature
Re: Limit Mail Submission to inet4
On Thu, Nov 18, 2021 at 10:55:00AM +0100, Simon Hoffmann wrote: > > > > > > >GMail still wont accept my IPv6 submitted mails. > > > > Are you using ipv6 connectivity over tunnel from tunnelbroker.net? > > Nope. My relays have "real" IPv6 /64 networks assigned to their interfaces > natively. > > However, I'd still like to only use IPv4 when sending messages. Why? Why not fix the IPv6 issue? Our servers deliver to gmail over IPv6 with no issues. > Suggestions? Set a fixed IPv4 source address using the src parameter in the action directive of your smtpd.conf.
Re: Limit Mail Submission to inet4
> > > >GMail still wont accept my IPv6 submitted mails. > > Hi, > > Are you using ipv6 connectivity over tunnel from tunnelbroker.net? Nope. My relays have "real" IPv6 /64 networks assigned to their interfaces natively. However, I'd still like to only use IPv4 when sending messages. Suggestions? Thanks! Simon signature.asc Description: PGP signature
