Re: [gentoo-user] Thunderbird 78
On 8/20/20 8:19 PM, Jack wrote: On 2020.08.20 18:42, james wrote: On 8/20/20 1:20 PM, Neil Bothwick wrote: On Thu, 20 Aug 2020 13:06:39 -0400, james wrote: As you do document all you are doing, and the information you gather, I see several interrelated but distinct areas.� hardware, software (several possibilities for each of several tasks,) network provisioning, and network configuration.� I'd prefer a better term for that last one - but I mean things like assuring your IP address doesn't end up (or start out) in a blacklisted block for any smtp attempts.� In my case, it's mostly that one (plus spam filtering) which gives me hesitation to attempt rolling my own. Black listing seems a valid issue. Here: Down the list is blacklisting. For me it is simple; if Blacklisting occurs, based on the IP addresses I get from Frontier, I'll just ask for different ones and cancel the bad (blacklisted) IPs. I'm telling Frontier up front, that is the reason for the IPs (to run email services) and my "commercial, extra cost" service with them. Power of the checkbook. Truthfully, I *should* be able to ferret out IP addresses that are blacklisted, right? This issue seems to now be the only impediment to continuing this email server(s) of static ip address(es). Frontier is in this document: https://www.ipvoid.com/ip-blacklist-check/ So I can just forward this list and any other tools that identify 'black listed IPs' to my sales contacts at Frontier, Verizon, Spectrum or any other ISP, willing to sell to me bandwidth, bonded with static IP addresses, right? James
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Fri, Aug 21, 2020 at 3:37 PM Grant Taylor wrote: > > On 8/21/20 6:37 AM, Rich Freeman wrote: > > This stuff can be interesting to discuss, but email is SO entrenched > > that I don't see any of this changing because of all the legacy issues. > > You would need to offer something that is both easier and better to > > use to such a degree that people are willing to change. > > "something that is /both/ *easier* and *better*". > > That's a VERY tall bar to clear. Hence I'm going to basically reply to only a few lines of your email - this isn't going to go anywhere so I really don't want to get into an endless argument about why people use webservices/etc. > What does JSON / XML / etc. on top of HTTP(S) provide that SMTP doesn't > provide? It is what just about every other modern application in existence uses. I'm sure there are hundreds of articles on the reasons for this that are far better than anything I'd come up with here. > > ... use more standard libraries/etc. > > There are many libraries to interface with SMTP. And they don't work for anything OTHER than SMTP. A library for JSON/webservices/whatever works for half the applications being written today. > > Stop focusing on HTTP(S) for a few minutes. > > If you were to create a new protocol from the ground up, why would you > introduce additional layers into the application stack — which represent > additional dependencies and complications — if you didn't have to? > > Not everything is a web server. Not everything can benefit from being > forced through a web server. This is simple. This is how just about EVERYBODY does it these days. http works as a transport mechanism. And obviously when I say http I mean http/https with the latter being preferred. That is the beauty of standards like this - somebody else figured out SSL on top of HTTP so we don't need an email-specific reimplementation of that. I mean, why use TCP? Why not use something more tailored to email? TCP probably has a dozen optional features that nobody uses with email, so why implement all that just to send email? The answer is that it makes WAY more sense to recycle a standard protocol than to invent one. If SMTP didn't exist, and we needed a way to post a bunch of data to a remote server, you'd use HTTP, because it already works. > > Most of the benefits only accrue if you adopt PKI as well, which is > > a problem that is hard to scale out to the masses. > > PKI is relatively easy to scale. (For a given value.) Hence the > thriving CA industry. > > Doing so in a trust worthy manner is the problem. Especially if you > want to avoid a single point of control / failure / GEO political / etc. It isn't just the trust problem. It is also the ease of use problem. Let's assume you trust all the CAs out there. Why isn't anybody using SSL for email? It is built into half the email clients out there. The problem is that exchanging certificates at an individual level is hard. Oh, for an organization with an IT department it isn't a problem. The IT department can just issue a certificate to everybody, generating keys for them. Then it can stick all the certs in some kind of directory that their email clients all use. Getting your cousin to use SSL certs for their email is a whole different matter. Heck, just using it between two different companies, both supported by professional IT depts, is a pain. You could use TLS for the transport itself and have the email servers configured to only use TLS for those domains, but actually doing E2E encryption is hard with email because there aren't a lot of standards for key exchange across unrelated orgs. > If we throw all the trusted CAs out the window, how do you /bootstrap/ > encrypted communications? - My personal opinion is DNS. > DNSSEC is: 1. Still poorly supported even where it makes sense. 2. A great hypothetical solution for the 0.002% of email users who own a domain name, like you and me. -- Rich
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
thanks. highly appreciate your time. to save
space i'll skip parts where i fully agree
with/happily-learned.
(e.g. loop detection; good reminder, i wasn't
thinking about it. plus didn't know of acronyms
DSN, MDNs, etc; nice keywords for further
googing).
‐‐‐ Original Message ‐‐‐
On Friday, August 21, 2020 8:59 PM, Grant Taylor
wrote:
> On 8/20/20 7:39 PM, Caveman Al Toraboran wrote:
>
> > 1. receipt by final mail server (mandatory).
> >
>
> You're missing the point that each and every single server along the
> path between the original submission server and the final destination
> server is on the hook for delivery of the message -or- notification of
> it's failure back to the purported sender address. So "final mail
> server" is not sufficient.
i was thinking (and still) if such relay-by-relay
delivery increases probability of error by a
factor of n (n = number of relays in the middle).
e.g. probability of accidental silent mail loss is
if one, or more, accidentally said "yes got it!"
but actually didn't. i.e.:
Pr(silent loss) =
sum_{k=1}^n
{n choose k}
* Pr(mistake)**k
* Pr(no mistake)**{n-k}
n = number of relays in the middle.
* = mult.
** = exponent.
i wonder if it would be better if only the entry
relay aims at the confirmation from the terminal
server? this way we won't need to assume that
relays in the middle are honouring their guarantees,
hence the probability above would be smaller since
k is limited up to 2 despite n's growth.
> Of course, there are servers that go against the RFC "MUST" directives
> and either don't safely commit messages to disk /before/ saying
> "Okay..." and / or don't deliver failure messages.
care to point part of the rfc that defines "safe"
commit to disk? e.g. how far does the rfc expect
us to go? should we execute `sync`'s equivalent
to ensure that data is actually written on disk
and is not in operating system's file system write
buffer?
> Signing will be of somewhat limited value as it will quite likely be
> subject to the same problem that DMARC / ARC suffer from now. Mail
> servers can sign what they receive. But in doing so, they alter what is
> sent to include their signature. As such, the data that the next server
> receives is different. The real problem is working backwards. Down
> stream servers don't have a reliable way to undo what upstream servers
> have done to be able to get back to the original message to validate
> signatures.
onion signatures? e.g. message is wrapped around
several layers of signatures for every relay in
the path?
> > this way we can have group-level rules.
>
> I'm not quite sure what you mean by group-level rules in this context.
e.g. whitelisting, tagging, spam filtration,
prioritizing, etc, based on entities that
onion-signed the message.
Re: [gentoo-user] Thunderbird 78
On 21/08/2020 15:36, Jack wrote: > On 8/21/20 8:28 AM, Victor Ivanov wrote: > I seem to be slow on the pickup with parts of this thread, but I'm not > sure exactly what you are looking for here. I assume you did find how > Balsa handles encryption for sending and receiving mail. If you are > talking about encrypting the local storage of all or selected messages, > I agree it is not a current option. Apologies, I kind of didn't want to fully hijack the thread. You're almost correct except that I'd like to encrypt the remote storage, not the local. Since IMAP works in both directions and allows for a full message, including headers, to be pushed to a given folder (handy for provider migration) one can use this feature to: (1) download a message in full (2) PGP encrypt the message according to RFC and a key of choice (3) push the encrypted message to the server (4) delete/expunge the previous, unencrypted message Both TB/Enigmail and KMail can use this technique to permanently decrypt a PGP encrypted message. The reverse, however, is a bit more clunky. KMail, has a working PGP encrypt filter but its message pushing is not always RFC compliant when it issues the IMAP "APPEND" command to push the message. It uses the current date/time instead of the one in the message's "Date" header which should take precedence according to RFC. This only appears to happen with multi-part messages, is easily reproducible even without PGP, and I have filed a bug report which has never been looked into. Plain-text messages are APPENDed correctly. The net result here is that as some providers, such as GMail, use the timestamp provided in the APPEND command to overwrite the message's Date header this leads to incorrect date/time indexing in folders/labels. So an old message now becomes recent when uploaded. KMail also fails to expunge the old message properly leaving the unencrypted message in addition to the newly pushed encrypted. TB/Enigmail too offers an "Encrypt to key" filter which ought to do the job but is completely broken and does not work at all. On the other hand pushing a message via IMAP works correctly for both plain-text and multi-part messages. The other mail clients that I have mentioned all have a correct APPEND implementation but do not seem to have an option (or filter choices) to perform the PGP procedure above. I'm hopeful that TB 78.2 will have this feature in one form or another. - V signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Friday, August 21, 2020 4:28 PM, Wols Lists wrote: > You're re-inventing the wheel. yes, i do consider re-inventing octagonal wheels. though this wasn't my point here. here, i'm just "asking" to see what makes the "safely stored" guarantee. perhaps i should've asked more directly (and yes, i know these are not new features). > > 1. receipt by final mail server (mandatory). > > > > This is part of SMTP already, in that each server (post office) > acknowledges that the message has been received AND SAFELY STORED. > Without that last guarantee, "receipt by the server" isn't worth > diddley-squat. got any specific definition of what makes a storage "guaranteed"? e.g. what kind of tests does the mail server do in order to say "yup, i can now guarantee this is stored safely!"? > > the job of a relay would be to optionally add some > > metadata (e.g. maybe describing sender's role) and > > sign the whole thing (e.g. by company's private > > key). this way we can have group-level rules. > > Except that SMTP allows for the fact that a message may (or may not) > pass through several post-offices on the way. The old internet thing of > "don't assume any computer will survive a nuclear attack - take whatever > route you can find ..." so there is no guarantee that a relay going in > one direction will even see a message going back in the other. so? not sure how this relates to what i said. i guess you think that i meant that a relay should be mandatory? or maybe i'm misunderstanding your point? (yes, a relay doesn't have to be used. i'm just describing some uses of relays that i think make sense. (1) indicate trust hierarchy, (2) offload mail delivery so that i can close my laptop and let the relay have fun with the retries. not sure there is any other use. anyone?)
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 11:54 AM, Caveman Al Toraboran wrote: thanks. highly appreciate your time. to save space i'll skip parts where i fully agree with/happily-learned. You're welcome. (e.g. loop detection; good reminder, i wasn't thinking about it. plus didn't know of acronyms DSN, MDNs, etc; nice keywords for further googing). ;-) i was thinking (and still) if such relay-by-relay delivery increases probability of error by a factor of n (n = number of relays in the middle). e.g. probability of accidental silent mail loss is if one, or more, accidentally said "yes got it!" but actually didn't. i.e.: It definitely won't be a factor of n, where n is the number of relays. i wonder if it would be better if only the entry relay aims at the confirmation from the terminal server? this way we won't need to assume that relays in the middle are honouring their guarantees, hence the probability above would be smaller since k is limited up to 2 despite n's growth. Nope. Each and every server MUST behave the same way. care to point part of the rfc that defines "safe" commit to disk? e.g. how far does the rfc expect us to go? should we execute `sync`'s equivalent to ensure that data is actually written on disk and is not in operating system's file system write buffer? TL;DR: Yes on all accounts. See the recent reply about guarantee and relays for more details. onion signatures? e.g. message is wrapped around several layers of signatures for every relay in the path? That doesn't help the problem. We sort of have an onion already. It's quite likely possible to validate the signature of the immediate sending server. But how does the receiving server know how to undo any modifications that the immediate sending server made to be able to validate the previous sending server's signature? Rinse, later, repeat out multiple levels. What if some of the servers signs what they send vs what they receive? These are the types of problems that don't currently have a solution. e.g. whitelisting, tagging, spam filtration, prioritizing, etc, based on entities that onion-signed the message. How is doing those things based on signature different than doing them based on the system sending to you? The only thing that comes to mind is trusting an upstream signature, but not the immediate sending system. But, you have to unwrap the onion to be able to validate the signature. But to do that you need to know what the server(s) downstream of the signature being validated did to the message. Some of this is a one way trap door without any indication of what each trap door did to the message. -- Grant. . . . unix || die
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 11:01 AM, Caveman Al Toraboran wrote: yes, i do consider re-inventing octagonal wheels. I think that it's occasionally a good thing to have a thought experiment about how $THING might be made better. It's probably good to have discussions around green feel types of replacements. But it's important to eventually assess the pros and cons of the old (as it exists), the new (as from green field), and the transition between the two. Sometimes the new doesn't warrant the transition, but it does provide an option that might be worth augmenting into the old. If nothing else, it's good to have the discussions and be able to answer why something was done or chosen to remain the same. here, i'm just "asking" to see what makes the "safely stored" guarantee. MTAs are supposed to be written such that they commit the message to persistent storage medium (disk) before returning an OK message to the sending server. There is some nebulous area around what that actually means. But the idea is that the receiving server believes, in good faith, that it has committed the message to persistent storage. Usually this involves writing the message to disk, probably via a buffered channel, and then issued system calls to ask the OS to flush the buffer to disk. Is there room for error? Probably. Had the server made (more than) reasonable effort to commit the message to disk? Yes. The point being, don't acknowledge receipt of the message while the message is only in the MTA's memory buffer. Take some steps to commit it to persistent storage. That being said, there are some questionable servers / configurations that will bypass this safety step in the name of performance. And they /do/ /loose/ /email/ as a negative side effect if (when) they do crash. This is a non-default behavior that has been explicitly chosen by the administrators to violate the SMTP specification. Some MTAs will log a warning that they are configured to violate RFCs. got any specific definition of what makes a storage "guaranteed"? e.g. what kind of tests does the mail server do in order to say "yup, i can now guarantee this is stored safely!"? It's more that they do something safe (write the message to disk) instead of risky (only store it in memory). Everything can fail at some point. It's a matter of what and how many reasonable steps did you take to be safe. Read: Don't cut corners and do something risky. i guess you think that i meant that a relay should be mandatory? Sending / outbound SMTP servers /are/ a relay for any messages not destined to the local server. There is almost always at least two SMTP servers involved in any given email delivery. All but the final receiving system is a relay. (yes, a relay doesn't have to be used. i'm just describing some uses of relays that i think make sense. (1) indicate trust hierarchy, (2) offload mail delivery so that i can close my laptop and let the relay have fun with the retries. not sure there is any other use. anyone?) There are many uses for email relays. A common one, and best practice, is to have an /inbound/ relay, commonly known as a backup email server. The idea being it can receive inbound messages while the primary email server is down (presumably for maintenance). Many SaaS Email Service Providers (ESPs) /are/ relay servers. They receive email from someone and send it to someone else. A number of email hygiene appliances function as an email relay between the world and your ultimate internal email server. Services that filter inbound email qualify here too. It is common, and I think it's best practice, to have web applications send email via localhost, which is usually a relay to a more capable hub email server which sends outbound email. Both of these layers are relays. A relay is the same thing for email that a router is for a network. -- Grant. . . . unix || die
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 6:37 AM, Rich Freeman wrote: This stuff can be interesting to discuss, but email is SO entrenched that I don't see any of this changing because of all the legacy issues. You would need to offer something that is both easier and better to use to such a degree that people are willing to change. "something that is /both/ *easier* and *better*". That's a VERY tall bar to clear. 1. Modernizing the actual data exchange using http/etc. I don't think you'll get much argument that SMTP isn't the way somebody would do things if they were designing everything from scratch. SMTP may not be the best, but I do think that it has some merits. Merits that the previously mentioned HTTP/2 alternative misses. Remember, SMTP is a protocol, or a set of rules, for how two email servers are supposed to exchange email. These rules include the following: 1) Proper server greeting, used to identify the features that can be used. (HELO for SMTP and EHLO for ESMTP.) 2) Identifying the sender. 3) Identifying the recipient(s). 4) Sending the message payload. Each of these discrete steps is a bi-directional communication. Communication that can alter all subsequent aspects of a given SMTP exchange. The server could be an older server that only speaks SMTP and as such doesn't support STARTTLS. Thus causing the client to /not/ try to use STARTTLS in accordance with current best practices. Other ESMTP features come into play here like message size, 8-bit, notification features, etc. The receiving server has the ability to assess the sending server's behavior at each point to use that as an indication to know if the sender is a legitimate email server or something more nefarious and undesirable. -- There is a surprising amount of email hygiene based on sending server's behavior. The receiving server may carte blanch reject messages from specific senders / sending domains and / or specific recipients, particularly non-existent recipients. SMTP has low overhead in that the message body is not transferred from the sending server to the receiving server if any part of steps 1-3 aren't satisfactory to the receiving server. I'm not an API expert but I imagine that just about any of the modern alternatives would be an improvement. Maybe. Maybe not. What is the actual problem with SMTP as it is? What /need/ to be improved? What could benefit from improvement even if it's not /needed/? http would be a pretty likely protocol to handle the transportation, Why HTTP? Did you mean to imply HTTPS? Why add an additional protocol to the stack? TCP / SMTP is two layers. TCP / HTTP / $Email-protocol-de-jure is three layers. UDP / HTTP / $Email-protocol-de-jusre is three layers. Why introduce an additional layer? Why introduce an additional dependency in the application stack? Why co-mingle email with other non-email traffic? -- Or are you wanting to run HTTP(S) on TCP port 25? likely with something like JSON/xml/etc carrying the payload. Why add an additional encapsulation on top of the additional layer? What does JSON / XML / etc. on top of HTTP(S) provide that SMTP doesn't provide? What is the gain? Is the gain worth the cost of doing so? You might want to tweak things slightly so that recipient validity can be tested prior to transferring data. Definitely. (See above for more details as to why.) But now you are doing multiple exchanges. If we extrapolate this out to also include sender validation, and probably hello messages, you are back to four or more exchanges. How is this better than SMTP on TCP port 25? What is the benefit? What does it cost to get this benefit? A mail server doesn't want to accept a 20MB encrypted payload if it can bounce the whole message based on the recipient or a non-authenticated sender or whatever. Which is one of the many reasons why there are multiple exchanges back and forth. However, in principle there are plenty of modern ways to build a transport protocol that would be an improvement on SMTP ... Please elaborate. Please include what network layer (3) protocol(s) you want to use and why. Please include what application layer (7) protocol(s) you want to use and why. Please include any encoding / encapsulation you want to use and why. ... use more standard libraries/etc. There are many libraries to interface with SMTP. Also, handing a message off to an SMTP server alleviates the application from having to deal with failed deliveries, queuing, and retrying. Why add that complexity into each and every application? Especially if you don't have to? Note: Pulling it in via a library is still indirectly adding it to each and every application. How is SMTP /not/ standard? Also: https://xkcd.com/927/ -- Standards I think this is actually the part of your proposal that might be more likely to take off. You could have a new type of MX field in DNS ... So yet more complexity in ad
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/20/20 7:39 PM, Caveman Al Toraboran wrote: 1. receipt by final mail server (mandatory). You're missing the point that each and every single server along the path between the original submission server and the final destination server is on the hook for delivery of the message -or- notification of it's failure back to the purported sender address. So "final mail server" is not sufficient. Each receiving server in the chain tells the sending server a definitive message that means "Okay, I've received the message and I will dutifully pass it on to the next server -or- report a problem." The RFCs defining SMTP don't consider a server crashing / power failing / etc. after saying "Okay..." as sufficient reason to fail to perform the job. Even in the event of a crash / power fail, the receiving server MUST process the email when it recovers. Of course, there are servers that go against the RFC "MUST" directives and either don't safely commit messages to disk /before/ saying "Okay..." and / or don't deliver failure messages. There are still other servers that don't accept such incoming failure notices. Both of which are against RFC "MUST" directives and as such violating the SMTP specification and thereby breaking interoperability. Particularly the "trust" part there of. These failure notifications have standardized on Delivery Status Notification, a.k.a. DSN, and historically called a "bounce". There has been evolution from many disparate formats of a bounce to an industry standard DSN. Said industry standard DSN is defined in RFCs. DSNs MUST be non-optional for failure. The only exception is if the sending system uses an extra option to specify that a DSN should /not/ be sent in the event of a failure. Receiving systems are compelled to send DSNs in the absence of said option. 2. receipt by end user(s) (optional). 3. opening by end user(s) (optional). These notifications are generally considered to be Message Disposition Notifications, and are optional. Further, the client is what sends MDNs /if/ it chooses to do so. MDNs are even more unreliable than DSNs. (1) is required by the server, else mail will be retransmitted from source relay(s) (or client if done directly). (2) is optional by final server, (3) is optional by end user's client. #1 is generated by RFC compliant servers. Not all servers are RFC compliant. #2 and #3 are generated by end user clients. Not all clients are willing to to do so. the job of a relay would be to optionally add some metadata This really isn't optional. *SOMETHING* /standard/ *MUST* be added. If for no other reason than to detect and prevent loops. (e.g. maybe describing sender's role) and sign the whole thing (e.g. by company's private key). I would suggest a /server's/ private key, and *NOT* the company's private key. There is a HUGE difference in potential for private key exposure. If one server is compromised, the entire company could be crippled if the /company's/ private key is used. Conversely, if the /server's/ private key is used, then /only/ /the/ /server/ is compromised. It is quite possible to have the company's public key published such that the company's internal CA can issue individual keys to each server. Signing will be of somewhat limited value as it will quite likely be subject to the same problem that DMARC / ARC suffer from now. Mail servers can sign what they receive. But in doing so, they alter what is sent to include their signature. As such, the data that the next server receives is different. The real problem is working backwards. Down stream servers don't have a reliable way to undo what upstream servers have done to be able to get back to the original message to validate signatures. There is also the fact that various fields of the email are allowed to have specific trivial modifications made to them, such a line wrapping or character encoding conversion. Such changes don't alter the content of the message, but they do alter the bit pattern of the message. These types of changes are even more difficult to detect and unroll as part of signature validation. this way we can have group-level rules. I'm not quite sure what you mean by group-level rules in this context. -- Grant. . . . unix || die
Re: [gentoo-user] Thunderbird 78
On 8/20/20 8:19 PM, Jack wrote: On 2020.08.20 18:42, james wrote: On 8/20/20 1:20 PM, Neil Bothwick wrote: On Thu, 20 Aug 2020 13:06:39 -0400, james wrote: Look at what I just received: From "Dear User Your Verizon✔ Version is outdated and has expired in the database as you know we are moving our Email Platform to AOl Mail. Failure to Upgrade to the newest Verizon✔ AOL Version 12.9 will result in inefficient usage of mailbox and might result to shutdown UPDATE HERE to Visit your login page Log-in to restore. Thanks Verizon✔ My Account Verizon✔ © 2020 All Right reserved " That looks like a phishing mail to me. OK. How do I verify or ferret out this to know. Ferret out what? Thunderbird on gentoo is vulnerable? Vulnerable to what? Any email client is subject to receiving SPAM and phishing attempts. Some email clients do have some amount of filtering included, and there are plenty of addons available. I used one of the Bayesian based ones for a while (can't remember the name) and finally gave up due to the difficulty of integrating with Balsa's pop3 fetching. As I remember, it would have been easier to integrate with a mail server than with the client. I've charted my own pathway, via R.P.4 boards and static IP addresses. That way, I can add whatever I want, test, and just run very few codes on those arm8 boards Sure, this has been on my todo list, as I prepare to live/work out of a RV. Eventually, I'll add a satellite link, when all else fails, without large attached files. I'm keeping the home, where the hub/static-IPs will connect, but I can be home or mobile, controlling my own email servers. I've just groan very tired of someone else managing and making decisions on MY email. I've received too many private emails from folks, with the same sentiment. If what I do is well documented, then a plethora of folks can have custom setups, in a well documented fashion. Mine is the hard case with the eventual address of daily mobility, cellular and satellite comms. Migration to R.P.4 has been on my goals list too, for a while. MY goal, via gentoo, is to fix and document this once and for ALL. Your expertise and the rest of the band of Gentoo folks are deeply appreciated in this effort. This action has been brewing for a few years. Email is critical for me, and I do not want vendors dictating its future for me. Enough is Enough. As you do document all you are doing, and the information you gather, I see several interrelated but distinct areas. hardware, software (several possibilities for each of several tasks,) network provisioning, and network configuration. I'd prefer a better term for that last one - but I mean things like assuring your IP address doesn't end up (or start out) in a blacklisted block for any smtp attempts. In my case, it's mostly that one (plus spam filtering) which gives me hesitation to attempt rolling my own. So can/how to I research if the IPv6 addresses offered have been blacklisted ? Same question, should I be able to get (2) IPv4 address. So if I request they are out of different blocks of IPv4, is that better? Just (2) single IP addresses from different blocks? Nest week I start that conversation with carriers. With what I have seen and heard, you'd think carriers, the folks with fiber in the ground, would be happy for a guy like me build a robust and secure email server services system. After all, it is their "ineptness" of employee selection that causes them such pains to run an email system. Surely punting to AOL and such, brings them little or no revenue (speculation on my part). Any insight to these venues, would help me negotiate the resources I need. Surely, this is just for me and a few friends. But, what I read and what other technical friends tell me, is this is an eruption waiting to happen. For many long time unix/bsd/linux folks email is a most critical tool for daily endeavors. The amount of code-snippets alone, in mine, is a treasure trove. James James Jack So
Re: [gentoo-user] Thunderbird 78
On 8/21/20 8:28 AM, Victor Ivanov wrote: On 21/08/2020 01:28, Jack wrote: Per my suggtion elsewhere in the thread, have you tried Balsa? I hadn't heard of Balsa up until this thread. It's minimalistic. I like it. But it too fails to satisfy the PGP requirement for filtering and encrypting existing mail. Unless I somehow failed to find the relevant filtering options (v2.6.1). I seem to be slow on the pickup with parts of this thread, but I'm not sure exactly what you are looking for here. I assume you did find how Balsa handles encryption for sending and receiving mail. If you are talking about encrypting the local storage of all or selected messages, I agree it is not a current option. However, from my experience dealing with the development team, they are likely to be receptive to a request/suggestion. I'll be glad to forward the request to them, but only if I better understand what I'm asking them to do.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Thu, Aug 20, 2020 at 9:39 PM Caveman Al Toraboran wrote: > > ‐‐‐ Original Message ‐‐‐ > On Thursday, August 20, 2020 11:41 AM, antlists > wrote: > > > Will that python script allow for the situation that the message is > > received, but the message was NOT safely stored for onwards transmission > > before the receiver crashed, and as such the message has not been > > SUCCESSFULLY received? > > > > SMTP has lots of things specifically meant to ensure messages survive > > the internet jungle on their journey ... > > thanks for the point. would it suffice if we have > these notifications: > > 1. receipt by final mail server (mandatory). > 2. receipt by end user(s) (optional). > 3. opening by end user(s) (optional). > I don't really want to get into the gory details and have only skimmed the discussion, but my sense is that you're talking about a new way to deliver mail that makes two sorts of changes: 1. Modernizing the actual data exchange using http/etc. 2. Changing the model around email moving to something more PKI-based/etc and redefining what an email address is. This stuff can be interesting to discuss, but email is SO entrenched that I don't see any of this changing because of all the legacy issues. You would need to offer something that is both easier and better to use to such a degree that people are willing to change. However, I'll comment on both of these issues: 1. Modernizing the actual data exchange using http/etc. I don't think you'll get much argument that SMTP isn't the way somebody would do things if they were designing everything from scratch. I'm not an API expert but I imagine that just about any of the modern alternatives would be an improvement. http would be a pretty likely protocol to handle the transportation, likely with something like JSON/xml/etc carrying the payload. You might want to tweak things slightly so that recipient validity can be tested prior to transferring data. A mail server doesn't want to accept a 20MB encrypted payload if it can bounce the whole message based on the recipient or a non-authenticated sender or whatever. However, in principle there are plenty of modern ways to build a transport protocol that would be an improvement on SMTP and use more standard libraries/etc. I think this is actually the part of your proposal that might be more likely to take off. You could have a new type of MX field in DNS and if it is set then it defines servers that will use the new protocol, and you could have backup SMTP servers for legacy transition. You could change the transport side of things without redefining how email works, so the same messages are interoperable with both systems. On the flip side, while I think this is an easier change to make, I don't think it necessarily offers huge improvements. SMTP still gets the job done, and the new system wouldn't really be a major improvement from a sysadmin standpoint, so I don't see everybody running out to change. Just changing the transport protocols doesn't provide any anti-spam/etc benefits. SMTP already supports TLS so it isn't any more secure. No doubt if we were starting from scratch this is how it would be done, but it isn't enough of a reason to change. That said, if there were even modest benefits for large mail providers I could see it taking off simply because it could leverage a lot of existing libraries and standards, and could have legacy compatibility. 2. Changing the model around email moving to something more PKI-based/etc and redefining what an email address is. This is where you could have revolutionary improvements for privacy/spam/etc. However, it completely breaks everything that exists with email today, so it is a hard change. Most of the benefits only accrue if you adopt PKI as well, which is a problem that is hard to scale out to the masses. If somebody comes up with a way to make PKI take off in a real way, then I could see something like this taking off eventually. Otherwise, this stuff is only going to be of interest to the sorts who use gpg to sign their email, and nobody else. -- Rich
Re: [gentoo-user] Memory cards, device notifier and remembering sd* designations.
On Thursday, 20 August 2020 21:50:28 BST Dale wrote: > new problem. I have one card that tests fine. I've reformatted it a > couple times but device notifier, DN, just will not see that it has been > plugged in. Does udisks see it? Have you tried plugging it in, while keeping an eye on the output of: $ udisksctl monitor udisks will identify the device being plugged in, the formatted block device on it, and finally any partitions on the fs, in consequent sections in its output. > I tried a different card reader, different adapter for > going from a TF or micro to SD card etc. Other cards I plug in work > like they should. I can mount the weird card manually without error. > The pictures on it were fine. No sign of corruption at all. I think > what happened, I mounted it manually the other day. I seem to recall > reading somewhere that if you mount something manually, DN won't mount > it for you in the future until you tell it to forget the manual > mounting. I use Plasma's DN, udisks, pmount and even manual mount as root occasionally, but have not come across this problem yet. However, I do not use DN's automounting. > Thing is, I can't find where that is stored so I can remove > it. Maybe it isn't supposed to do that anymore but is anyway. Does > anyone know where those settings are stored? Anyone know where I go to > tell it to see the card and offer to mount it with DN? I've looked > everywhere I can think of for this. Perhaps it is stored in some akonadi entry, or some .qmcl setting. In the first instance I suggest you right click on the Device Notifier in the Plasma tool tray, then select 'Configure Removable Devices' and un-tick: - Only automatically mount removable media that has been mounted before - Enable automatic mounting of removable media This will hopefully flush out any cached USB drive details. If you need these settings you can reset them later on. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Thunderbird 78
On 21/08/2020 01:28, Jack wrote: > Per my suggtion elsewhere in the thread, have you tried Balsa? I hadn't heard of Balsa up until this thread. It's minimalistic. I like it. But it too fails to satisfy the PGP requirement for filtering and encrypting existing mail. Unless I somehow failed to find the relevant filtering options (v2.6.1). > Can you elaborate on how threading and conversations are different? ... > In terms of combining sent and received messages, unless you are going > to have some way of showing conversations across folders (which don't > exist in gmail) the only way I can think of is to copy your sent > messages into the folder the replies are in, and I do sometimes do > this. I try to set all my mailing lists to send me copies of my own > messages, but doing a bcc to yourself would have the same effect. Well... that's exactly what "conversation" view is. I don't think I have much more to add. Sure, GMail uses labels instead of folders and emulates the latter in IMAP but that's totally irrelevant, so long as said "categories" are available to the mail client. Most email clients can be configured to sync either just mail headers or entire emails for the last X number of days (or all mail). So, at the very least, being able to have an "extended" threaded view (e.g. by means of a virtual folder - just like a unified inbox) so to speak that combines emails from both Inbox and Sent seems rather trivial and could be done whenever (re)indexing subscribed folders. BCC'ing myself or having both sent and incoming mail in one mailbox is a workaround - not a solution. It's neither elegant nor should it be necessary to achieve the above behaviour. KMail so far comes as close as it gets (from what I've seen) to customising threading and appearance of email listing though it too can't combine multiple folders. Anyway, as I said, the PGP and standalone (or exportable) config to me are more important in a mail client. "Conversation" view is more of a desirable feature rather than something I can't live without. - V signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 21/08/20 02:39, Caveman Al Toraboran wrote: > ‐‐‐ Original Message ‐‐‐ > On Thursday, August 20, 2020 11:41 AM, antlists > wrote: > >> Will that python script allow for the situation that the message is >> received, but the message was NOT safely stored for onwards transmission >> before the receiver crashed, and as such the message has not been >> SUCCESSFULLY received? >> >> SMTP has lots of things specifically meant to ensure messages survive >> the internet jungle on their journey ... > > thanks for the point. would it suffice if we have > these notifications: You're re-inventing the wheel. > > 1. receipt by final mail server (mandatory). This is part of SMTP already, in that each server (post office) acknowledges that the message has been received AND SAFELY STORED. Without that last guarantee, "receipt by the server" isn't worth diddley-squat. > 2. receipt by end user(s) (optional). This is part of current mail protocol - dunno what it's called but I can switch on a flag in Thunderbird, and I will get a message back saying my email is in the recipient's inbox. > 3. opening by end user(s) (optional). Likewise, I will get a notification that the email has been "read". > > ? > > > > (1) is required by the server, else mail will be > retransmitted from source relay(s) (or client if > done directly). (2) is optional by final server, > (3) is optional by end user's client. > > the job of a relay would be to optionally add some > metadata (e.g. maybe describing sender's role) and > sign the whole thing (e.g. by company's private > key). this way we can have group-level rules. > Except that SMTP allows for the fact that a message may (or may not) pass through several post-offices on the way. The old internet thing of "don't assume any computer will survive a nuclear attack - take whatever route you can find ..." so there is no guarantee that a relay going in one direction will even see a message going back in the other. And as an example of how hard this is, look at what a mess the telcos have made of SMS, which is basically the same thing! How often on New Year's Eve do (or did) the system fall over so all the "Happy New Year" messages either disappeared, or arrived several days late ... Cheers, Wol
