Re: [gentoo-user] Alternate Incoming Mail Server
On 4/11/20 4:13 PM, antlists wrote: Which was also a pain in the neck because it was single-threaded - if the ISP tried to send an incoming email at the same time the gateway tried to send, the gateway hung. Ew. I can't say as I'm surprised about that, given the nature of SMTP servers in the '90s. I wonder what the licensing would have been to have one machine sending outbound and another receiving inbound. Though that does assume that you could have multiple SMTP gateways connected to MS-Mail. You could pretty much guarantee most mornings I'd be in the server room deleting a bunch of private emails from the outgoing queue, and repeatedly rebooting until the queues in both directions managed to clear. Oy vey! The point is that when the server sends EHLO, it is *not* a *permitted* response for the client to drop the connection. That was the specification for ESMTP - the client should reject EHLO, the server tries again with HELO, and things (supposedly) proceed as they should. Which they can't, if the client improperly kills the connection. Agreed. Which shouldn't have been a problem. ESMTP was designed to fall back gracefully to SMTP. But if clients don't behave correctly as per the SMTP spec, how can the server degrade gracefully? I wonder how many Sun Sparc boxen were put between Microsoft mail infrastructure and the rest of the world in the '90s and '00s. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 11/04/2020 21:33, Grant Taylor wrote: On 4/11/20 2:08 PM, antlists wrote: Okay, it was a long time ago, and it was MS-Mail (Exchange's predecessor, for those who can remember back that far), but I had an argument with my boss. He was well annoyed with our ISP for complying with RFC's because they switched to ESMTP and MS-Mail promptly broke. I don't recall any RFC (from the time) stating that ESMTP was REQUIRED. It may have been a SHOULD. The ISP chose to make the change that resulted in ESMTP. Yes. But as per spec ESMTP was/is compatible with SMTP. Also, I'm fairly sure that MS-Mail didn't include SMTP in any capacity. It required an external MS-Mail SMTP gateway, which I Microsoft did sell, for an additional cost. Yes, it is the gateway I'm talking about ... Which was also a pain in the neck because it was single-threaded - if the ISP tried to send an incoming email at the same time the gateway tried to send, the gateway hung. You could pretty much guarantee most mornings I'd be in the server room deleting a bunch of private emails from the outgoing queue, and repeatedly rebooting until the queues in both directions managed to clear. The *ONLY* acceptable reason for terminating a connection is when you recieve the command "BYE", so when Pipex sent us the command EHLO, MS-Mail promptly dropped the connection ... I'll agree that what you're describing is per the (then) SMTP state machine. We have sense seen a LOT of discussion about when it is proper or not proper to close the SMTP connection. The point is that when the server sends EHLO, it is *not* a *permitted* response for the client to drop the connection. If the MS-Mail SMTP gateway sent a 5xy error response, it could see how it could subsequently close the connection per protocol state machine. Pipex, and I suspect other ISPs, had to implement an extended black list of customers who couldn't cope with ESMTP. If the MS-Mail SMTP gateway hadn't closed the connection and instead just returned an error for the command being unknown / unsupported, Pipex would have quite likely tried a standard HELO immediately after getting the response. That was the specification for ESMTP - the client should reject EHLO, the server tries again with HELO, and things (supposedly) proceed as they should. Which they can't, if the client improperly kills the connection. Also, we're talking about the late '90s during the introduction of ESMTP, which was a wild west time for SMTP. Which shouldn't have been a problem. ESMTP was designed to fall back gracefully to SMTP. But if clients don't behave correctly as per the SMTP spec, how can the server degrade gracefully? Cheers, Wol
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/11/20 4:41 PM, Grant Taylor wrote: > On 4/11/20 2:17 PM, Michael Orlitzky wrote: >> Exchange used to do all manner of stupid things, but now that Microsoft >> is running it themselves and making money from O365, they seem to have >> figured out how to make it send mail correctly. > > I've found that Exchange / IIS SMTP is fairly standards compliant since > the early-mid 2000s. > > Microsoft has always been making money off of Exchange. (Presuming > people are being legal about it.) Be it CALs, upgrade licensing, etc. Right, but back then, they already had your money by the time you realized Exchange was a turd. Now people can cancel their subscription, and Microsoft has to field support calls when things don't work, so they have a bit more incentive to do things right. >> Nowadays they prefer to cripple Outlook with non-Exchange protocols, >> so that our users complain about not having shared calendars when >> we've had CalDAV integrated with IMAP for 10+ years. > > CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP. > > ... > > So, IMHO, complaining that Outlook doesn't support CalDAV is sort of > like complaining that Firefox doesn't support SIP telephony. Could it > if it wanted to, sure. Should it, maybe. Does it, no. Outlook has (shared) calendars and contacts built-in for 20+ years. What's missing is the support for the standard CalDAV and CardDAV protocols in addition to the proprietary MS ones. I agree that an email client shouldn't do calendars and contacts to begin with, but that battle was lost when I was in high school.
Re: [gentoo-user] Alternate Incoming Mail Server
On Sat, Apr 11, 2020 at 02:41:35PM -0600, Grant Taylor wrote: > On 4/11/20 2:17 PM, Michael Orlitzky wrote: > > Nowadays they prefer to cripple Outlook with non-Exchange protocols, so > > that our users complain about not having shared calendars when we've had > > CalDAV integrated with IMAP for 10+ years. > > CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP. > > I'm not aware of Outlook ever claiming support for CalDAV. It has supported > POP3, IMAP, SMTP, Exchange proprietary protocols, and likely NNTP. The closest you could get on M.S.\ Windows is the "e-mail" application, which added some limited support for CalDAV but also placed some rather severe restrictions on providers. C.f. https://www.ctrl.blog/entry/windows-pim-sync-partnersonly.html -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/11/20 2:17 PM, Michael Orlitzky wrote: Exchange used to do all manner of stupid things, but now that Microsoft is running it themselves and making money from O365, they seem to have figured out how to make it send mail correctly. I've found that Exchange / IIS SMTP is fairly standards compliant since the early-mid 2000s. Microsoft has always been making money off of Exchange. (Presuming people are being legal about it.) Be it CALs, upgrade licensing, etc. Nowadays they prefer to cripple Outlook with non-Exchange protocols, so that our users complain about not having shared calendars when we've had CalDAV integrated with IMAP for 10+ years. CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP. I'm not aware of Outlook ever claiming support for CalDAV. It has supported POP3, IMAP, SMTP, Exchange proprietary protocols, and likely NNTP. You can get shared calendaring, address books, and folders without Exchange. I used MAPIlab's Colab product for a number of clients for many years circa 2010. It is (was?) an Outlook add-on that added support for accessing a shared PST file. It worked great in multiple client's offices of between 5 and 25 people. (My bigger clients had Exchange.) So, IMHO, complaining that Outlook doesn't support CalDAV is sort of like complaining that Firefox doesn't support SIP telephony. Could it if it wanted to, sure. Should it, maybe. Does it, no. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/11/20 2:08 PM, antlists wrote: Okay, it was a long time ago, and it was MS-Mail (Exchange's predecessor, for those who can remember back that far), but I had an argument with my boss. He was well annoyed with our ISP for complying with RFC's because they switched to ESMTP and MS-Mail promptly broke. I don't recall any RFC (from the time) stating that ESMTP was REQUIRED. It may have been a SHOULD. The ISP chose to make the change that resulted in ESMTP. Also, I'm fairly sure that MS-Mail didn't include SMTP in any capacity. It required an external MS-Mail SMTP gateway, which I Microsoft did sell, for an additional cost. The *ONLY* acceptable reason for terminating a connection is when you recieve the command "BYE", so when Pipex sent us the command EHLO, MS-Mail promptly dropped the connection ... I'll agree that what you're describing is per the (then) SMTP state machine. We have sense seen a LOT of discussion about when it is proper or not proper to close the SMTP connection. If the MS-Mail SMTP gateway sent a 5xy error response, it could see how it could subsequently close the connection per protocol state machine. Pipex, and I suspect other ISPs, had to implement an extended black list of customers who couldn't cope with ESMTP. If the MS-Mail SMTP gateway hadn't closed the connection and instead just returned an error for the command being unknown / unsupported, Pipex would have quite likely tried a standard HELO immediately after getting the response. Also, we're talking about the late '90s during the introduction of ESMTP, which was a wild west time for SMTP. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/11/20 4:08 PM, antlists wrote: > > Okay, it was a long time ago, and it was MS-Mail (Exchange's > predecessor, for those who can remember back that far), but I had an > argument with my boss. He was well annoyed with our ISP for complying > with RFC's because they switched to ESMTP and MS-Mail promptly broke. > The *ONLY* acceptable reason for terminating a connection is when you > recieve the command "BYE", so when Pipex sent us the command EHLO, > MS-Mail promptly dropped the connection ... > Exchange used to do all manner of stupid things, but now that Microsoft is running it themselves and making money from O365, they seem to have figured out how to make it send mail correctly. Nowadays they prefer to cripple Outlook with non-Exchange protocols, so that our users complain about not having shared calendars when we've had CalDAV integrated with IMAP for 10+ years.
Re: [gentoo-user] Alternate Incoming Mail Server
On 06/04/2020 14:08, Ashley Dixon wrote: After my thankfully-brief experience with the likes of Microsoft and their Exchange program, I always question how much impact the content of an R.F.C. actually has on an implementation. :-) Okay, it was a long time ago, and it was MS-Mail (Exchange's predecessor, for those who can remember back that far), but I had an argument with my boss. He was well annoyed with our ISP for complying with RFC's because they switched to ESMTP and MS-Mail promptly broke. The *ONLY* acceptable reason for terminating a connection is when you recieve the command "BYE", so when Pipex sent us the command EHLO, MS-Mail promptly dropped the connection ... Pipex, and I suspect other ISPs, had to implement an extended black list of customers who couldn't cope with ESMTP. Cheers, Wol
Re: [gentoo-user] Alternate Incoming Mail Server
On 07/04/2020 11:53, Ashley Dixon wrote: Grant's mail server, I assume, is configured with the highest security in mind, so I can see how a mail server with a dynamic I.P.\ could cause issues in some contexts. I just wish my I.S.P.\ offered_any_ sort of static I.P.\ package, but given that I live in remote area in the north of England, I.S.P.s aren't exactly plentiful. https://www.aa.net.uk/ Andrews and Arnold. From what I know of them, a fair few people who know what they're talking about say they're good. Sounds they're like what Demon were before Clueless and Witless took them over. Cheers, Wol
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
Am Dienstag, 7. April 2020, 01:38:01 CEST schrieb Michael: > On Monday, 6 April 2020 22:15:20 BST Neil Bothwick wrote: > > On Mon, 6 Apr 2020 22:02:04 +0100, antlists wrote: > > > > This isn't strictly true, the ESP must be vfat, but you can still > > > > have an ext? /boot. > > > > > > This isn't true at all - you've got the cart before the horse. The > > > original (U)EFI spec comes from Sun, I believe, with no vfat in sight. > > > > > > A standards-compliant factory-fresh Mac boots using UEFI with no vfat > > > in sight. > > > > That's true, but firmware on commodity PC motherboards can only be relied > > upon to handle vfat. So while my use of "must" is a bit strong, it should > > be vfat if you want to be sure it will boot on a PC. > > Perhaps older UEFI specifications allowed Mac-baked filesystems, or perhaps > Apple were/are doing their own thing. The current UEFI specification > *requires* a FAT 12/16/32 filesystem type on an ESP partition to boot an OS > image/bootloader from - see section '13.3 File System Format': > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf > > I can't recall the ESP partition format last time I installed and > dual-booted Linux on a MacBookPro, c.2014, but I'd wager it was VFAT. I checked my 2007 Mac Mini and its ESP is vfat. Of course, newer Macs or other models might use something else. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
[gentoo-user] gentoo-user+unsubscr...@lists.gentoo.org
-- Ted Ozolins Cranbrook, BC
Re: [gentoo-user] How to disable fuzzy-search in emerge?
On Fri, 10 Apr 2020 12:37:56 -0400, Jack wrote: > Even eix often finds things I think are irrelevant, but I know it's > searching on a regexp, so I'll often do "eix ^string$ if I know the > package and am just looking for the info about it. Use eix -e if you want an exact match. -- Neil Bothwick Top Oxymorons Number 31: Small crowd pgpufxTwS41Ju.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: How to disable fuzzy-search in emerge?
On Fri, 10 Apr 2020 17:00:08 - (UTC), Grant Edwards wrote: > I don't know why it didn't occur to me to check for a make.conf > variable instead of an environment variable or USE flag. Of course > now that I know that make.conf variable's name, I have found it in few > other places in the emerge man page, and there's a clear description > of it in make.conf(5). > > Unfortunately, the emerge man page doesn't really discuss make.conf > except for a few places where it's mentioned that some specific option > can be controlled via make.conf. Try the make.conf man page :) -- Neil Bothwick I spilled Spot remover on my dog. Now he's gone. pgpEaw3V_i1AB.pgp Description: OpenPGP digital signature
