Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On 8/26/20 7:07 PM, Ashley Dixon wrote: I meant (a), in the sense that you should probably write it up in a more presentable fashion than a GitHub README page. You might want to nicely typeset it in TeX or something to make it seem more serious. Just a suggestion... I'm sure there are those that will disagree with me. But I don't think it's as important how professional things look as long as they are sound ideas. Lest it be an ad hominem attack. Which, as previously indicated is not a good thing. Good ideas should be able to stand on their own. If Caveman's idea turns out to be deemed better on it's technical merits, then the text vs HTML vs TeX/LaTeX formatting shouldn't matter. In which language are you intending to write the reference implementation? I'd suggest writing it in a relatively low-level language, so it's easier to read and port without making too many assumptions. I would probably argue that using a mid to higher level language or even a pseudo code for documentation / explanation might be advisable. I think that it's more important to get the idea out, in a way that it's easily understandable and re-implementable by others. Is it better to have the first implementation be crem de la crem and the overall idea not be adopted? Or would it be better for the original implementation to fade into history while the concept takes over and surpasses current email solutions? You really need to define more goals and non-goals; two non-specific goals, and one non-goal really isn't enough to form an entire specification. I would suggest starting with a problem statement. Clearly document and articulate what you think is wrong with the current email solutions. After all, I believe that's the root of the motivation for this. Once you have a clear problem statement, start developing possible solutions. I encourage multiple -> many if not an order of magnitude more than the problems. Once you have multiple possibilities, then you can objectively compare and contrast the possibilities to see which one is the best. Additionally, I noticed that you have written that the "actual message" will be restricted to UTF-8 with no HTML/JS/CSS, which you collectively describe as "self-hating formats" (?). While I (and most on this list) despise the use of the aforementioned formats in e-mails to the appropriate extent, I struggle to see how you are going to prevent them being transmitted using HillaryMail. If there is anything that the industry is good at, it's encoding things such that they can be transported by something that can't natively support the unencoded thing. All of the control codes of HTML are fully representable in ASCII, which is a strict subset of Unicode. How are you going to prevent people transmitting HTML over the protocol? It is up to the client to parse the HTML into its intended aesthetic form; the server has nothing to do with it. The only solution I could imagine is rejecting all messages containing attachments with MIME types other than plain-utf8, but is that really a good idea? I think trying to restrict things will do more harm to the idea than the idea itself would do good. It's likely to cause people to reject it out of hand as why would they want to choose something that fights them? I am interested, but gravely skeptical. Well said. I am not overtly opposed to the concept of replacing SMTP and enhancing email. I just want to make sure that whatever eventually does replace SMTP does so because it can stand up to technical scrutiny far worse than anything I can throw at it. It should succeed because it really is better, not because someone wants it to be better. Historians will judge us and the decisions we make harshly, just like we judge our previous technical brethren harshly for their decisions. -- 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/18/20 6:44 PM, Grant Taylor wrote:
I will have to collect a list and get back to you.
Here are part of some crude notes that I created for myself to use to
build a Gentoo mail server about three years ago. This is the email
specific parts. The rest were for other non-email aspects.
Note: This just gets things installed. It doesn't do anything for how
to configure things. (I was copying config files between systems.)
The square brackets at the end of the line are dependencies. (I use the
word loosely.)
- eMail
- Sendmail (mail-mta/sendmail) [ipv6 sasl ssl]
- emerge -a mail-mta/sendmail
- chmod g+w /var/spool/mqueue
- rc-update add sendmail default
- {mc,cf} file
- certificates
- cp /etc/pam.d/{pop,smtp}
- touch /etc/mail/access
- makemap hash /etc/mail/access < /etc/mail/access
- touch /etc/mail/genericstable
- makemap hash /etc/mail/genericstable < /etc/mail/genericstable
- Cyrus-SASL (pulled in)
- rc-update add saslauthd default
- Nail (mail-client/nail) []
- emerge -a mail-client/nail
- Procmail (mail-filter/procmail) []
- emerge -a mail-filter/procmail
- Mutt (mail-client/mutt) []
- emerge -a mail-client/mutt
- SpamAssassin (mail-filter/spamassassin) [cron ipv6 ssl]
- emerge -a mail-filter/spamassassin
- rc-update add spamd default
- sa-update
- SpamAssassin Milter (mail-filter/spamass-milter) []
- emerge -a mail-filter/spamass-milter
- rc-update add spamass-milter default
- ClamAV (app-antivirus/clamav) [ipv6 milter]
- emerge -a app-antivirus/clamav
- rc-update add clamd default
- /etc/conf.d/clamd
- START_MILTER=yes
- SPF (mail-filter/libspf2) []
- emerge -a mail-filter/libspf2
- SRS (mail-filter/libsrs2) []
- emerge -a mail-filter/libsrs2
- OpenDKIM (mail-filter/opendkim) [ssl]
- echo "mail-filter/opendkim ldap" >
/etc/portage/package.use/opendkim
- emerge -a mail-filter/opendkim
- rc-update add XXX default
- OpenDMARC (mail-filter/opendmarc) []
- emerge -a mail-filter/opendmarc
- rc-update add XXX default
- CourierIMAP (net-mail/courier-imap) [ipv6]
- emerge -a net-mail/courier-imap
- /etc/courier/conf files
- mkimapcert
- mkdhparams
- rc-update add courier-imapd-ssl default
- Install valid SSL cert.
--
Grant. . . .
unix || die
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On Wed, Aug 26, 2020 at 08:33:58PM +, Caveman Al Toraboran wrote: > On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon > wrote: > > > Why the name "HillaryMail", and why does the logo contain a picture of > > Margaret Thatcher? ;-) > > very true (re: thatcher). now i cannot unsee the > thatcher in the pixel art. i have 2 options: > > (1) rename protocol into thatchermail. > (2) find another pixel art that's actually for > hillary. Nothing wrong with Thatcher. Although, British politics are less amusing than their American counterparts, but there are exceptions. https://www.youtube.com/watch?v=HDVwidaHwSc More seriously, as Grant said, it's probably best to stray away from this politically charged area entirely. Mentioning leaked e-mails of an American presidential candidate in the title of an e-mail solution is akin to naming an SSL implementation something like Heartbleedin'. It just gives off the completely wrong "vibe". > i got the thatcher pixel art from a site that > claimed it's hillary [1]. > > as for the name "hillarymail", nothing against > her. it's just that i heard so much about > hillary's mails up to a point all mails started to > feel as if they belong to her. Yes, but (I assume) there were not many positive reports. It does seem an odd thing after which to name an e-mail solution! > i intend to eventually write a reference > implementation either way (hopefully). specially > that this seems to me very easy to implement, yet > it seems also powerful. > > not sure what "formal r.f.c." means. > > (a) if it means a less ambiguous description, > then "yes, but at a natural pace based on > demand" (in the spirit of occam's razor). I meant (a), in the sense that you should probably write it up in a more presentable fashion than a GitHub README page. You might want to nicely typeset it in TeX or something to make it seem more serious. Just a suggestion... In which language are you intending to write the reference implementation? I'd suggest writing it in a relatively low-level language, so it's easier to read and port without making too many assumptions. > but if it is possible to make it easier while > still satisfying the constraints > (goals/non-goals), then that's a good step forward > (perhaps draft one?). You really need to define more goals and non-goals; two non-specific goals, and one non-goal really isn't enough to form an entire specification. Additionally, I noticed that you have written that the "actual message" will be restricted to UTF-8 with no HTML/JS/CSS, which you collectively describe as "self-hating formats" (?). While I (and most on this list) despise the use of the aforementioned formats in e-mails to the appropriate extent, I struggle to see how you are going to prevent them being transmitted using HillaryMail. All of the control codes of HTML are fully representable in ASCII, which is a strict subset of Unicode. How are you going to prevent people transmitting HTML over the protocol? It is up to the client to parse the HTML into its intended aesthetic form; the server has nothing to do with it. The only solution I could imagine is rejecting all messages containing attachments with MIME types other than plain-utf8, but is that really a good idea? I am interested, but gravely skeptical. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon wrote: > Why the name "HillaryMail", and why does the logo contain a picture of > Margaret > Thatcher? ;-) very true (re: thatcher). now i cannot unsee the thatcher in the pixel art. i have 2 options: (1) rename protocol into thatchermail. (2) find another pixel art that's actually for hillary. i got the thatcher pixel art from a site that claimed it's hillary [1]. as for the name "hillarymail", nothing against her. it's just that i heard so much about hillary's mails up to a point all mails started to feel as if they belong to her. i also named my passwords manager after nsa [2] for a similar reason (even though i find nsa to be much more trustworthy than my neighbours). > More seriously, do you intend to write a reference implementation, or submit > this as a more formal R.F.C. in the event of it attracting more attention? i intend to eventually write a reference implementation either way (hopefully). specially that this seems to me very easy to implement, yet it seems also powerful. not sure what "formal r.f.c." means. (a) if it means a less ambiguous description, then "yes, but at a natural pace based on demand" (in the spirit of occam's razor). (b) if it means an r.f.c. submitted to isoc/ietf, then "no". i think we should ignore standard bodies for awhile since they seem to be ignoring us. > Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the > best way of attaining support; I must admit, I have never seen that in an > initial protocol proposal. imo that's a parsing error on your side. to me "idiot" didn't refer to smtp/pop/imap users. it rather referred to those those who can't use address books or bitcoin. either way i've just replaced "idiots" by "people". "idiot" wasn't justified either way. > I'm also slightly confused regarding the "goals" section. By "easy to > install/use", do you mean "easy" for the people implementing the protocol, or > the people making use of said implementations? "Traditional" SMTP mail clients > have always been pretty straight-forward for me, although the difficulty > involved in implementing an M.T.A. is another story. I find this point rather > equivocal. i mean easy for both, but subject to the constraints specified under "goals" and "non-goals". e.g. if becoming easier would cause the protocol to end up needing to trust a sys admin, then that's not acceptable. but if it is possible to make it easier while still satisfying the constraints (goals/non-goals), then that's a good step forward (perhaps draft one?). -- [1] http://pixelartmaker.com/art/dffec5c6b08b94e [2] https://github.com/al-caveman/nsapass note: trying to remove pexpect dependency as it sometimes causes indefinite waiting. so it is not ready for those who want a solid app yet. that said, i really like it so far. imo after removing "pexpect" it will be perfect.
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On 8/26/20 3:33 PM, Grant Taylor wrote: I would suggest using any reference to Hillary Clinton. Typo: I would suggest *NOT* using any reference to Hillary Clinton. -- Grant. . . . unix || die
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On 8/26/20 2:33 PM, Caveman Al Toraboran wrote: as for the name "hillarymail", nothing against her. I would suggest using any reference to Hillary Clinton. I believe her name is too politically charged to use it in good faith. it's just that i heard so much about hillary's mails up to a point all mails started to feel as if they belong to her. Almost everything I heard about it seemed to be negative. What little I heard that wasn't negative was simply neutral. My opinion is that the name (independent of H.C.) and H.C.'s association would cause me to choose a different name. I'd suggest something that describes what it does. Note: I've not ready your proposal yet. I've earmarked to do so when I have more time. i intend to eventually write a reference implementation either way (hopefully). specially that this seems to me very easy to implement, yet it seems also powerful. "seems" is the operative word. I think you will find that there is MUCH more to it than what I think you think there is. not sure what "formal r.f.c." means. (a) if it means a less ambiguous description, then "yes, but at a natural pace based on demand" (in the spirit of occam's razor). How does Occam's Razor or Parsimony apply to this? (b) if it means an r.f.c. submitted to isoc/ietf, then "no". RFCs are decidedly outside of ISOC / IETF. i think we should ignore standard bodies for awhile since they seem to be ignoring us. Those sentiment / attitude is concerning to me. Just because you don't like something or disagree with it is not in and of itself a reason to ignore or avoid it. Especially when it is (RFCs are) the well established process to do something in the Internet community. imo that's a parsing error on your side. to me "idiot" didn't refer to smtp/pop/imap users. I would strongly suggest anything that can be construed as an ad hominem attack. it rather referred to those those who can't use address books or bitcoin. I think those are two very different things. Address books have existed for a long time and are included in all prominent devices / email clients in one form or another. The same can't be said about bitcoin. either way i've just replaced "idiots" by "people". "idiot" wasn't justified either way. There's no place, much less need for ad hominem attacks in standards documents, be they formal, e.g. ISO, IETF, or non-standards based, e.g. RFC. i mean easy for both, I find the goal of easy for the user to use and easy for the developer to develop to be almost diametrically opposed to each other. In my experience, it's either been a pay it forward once (developer) or pay it back perpetually (user). Which are you prioritizing? The developer or the user? I would strongly suggest the developer pay it forward so that the end users don't have to perpetually pay it back. but subject to the constraints specified under "goals" and "non-goals". e.g. if becoming easier would cause the protocol to end up needing to trust a sys admin, then that's not acceptable. Elaborate on what "trusting a system administrator" means and why it's not acceptable. I think you will find that there are regimes that will not allow technology that they can't see into and observe. As such, they will dictate that the technology trust the system administrator (regime). Lest they ban the technology. but if it is possible to make it easier while still satisfying the constraints (goals/non-goals), then that's a good step forward (perhaps draft one?). The requirement to go from informational RFC to standards track RFC is multiple independent implementations. So not only do you need to get your implementation working, but you also need to get someone else to completely independently create their own implementation and it must be interoperable with yours. Anything less and you'll never achieve anything but an informational RFC status. And you will need a standards track RFC status to get the big players to even think about entertaining the notion of this. -- Grant. . . . unix || die
[gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
hi. i request comments on this new mail protocol which i plan to implement some day if things turn out well. here is its zeroth draft: https://github.com/al-caveman/hillarymail rgrds, cm.
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On 8/26/20 1:57 PM, Ashley Dixon wrote: On Wed, Aug 26, 2020 at 05:19:16PM +, Caveman Al Toraboran wrote: hi. i request comments on this new mail protocol which i plan to implement some day if things turn out well. here is its zeroth draft: https://github.com/al-caveman/hillarymail I like what I see, so far. Interesting proposal. A few non-technical questions: Why the name "HillaryMail", and why does the logo contain a picture of Margaret Thatcher? ;-) More seriously, do you intend to write a reference implementation, or submit this as a more formal R.F.C. in the event of it attracting more attention? Nice idea. I suggest the R.P.4 so it can stay up 24/365. Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the best way of attaining support; I must admit, I have never seen that in an initial protocol proposal. I'll wear that moniker, as a follower and implementor and testor. I'm also slightly confused regarding the "goals" section. By "easy to install/use", do you mean "easy" for the people implementing the protocol, or the people making use of said implementations? "Traditional" SMTP mail clients have always been pretty straight-forward for me, although the difficulty involved in _implementing_ an M.T.A. is another story. I find this point rather equivocal. Whatever grant offers, surely I'll at least attempt to implement. email services are getting hammered, from a traditional functional perspective. I do not like what the big corps are doing and just want a standards complint , reasonable secure solution. Is there something better for me to follow than this offering from grant ? From the private emails I have received, over the last month or so, there is quite and interest in running your own (secure?) DNS and email services Perhaps there is a solution for the R.P.4 for other linux distros I have not found, yet? If so, I'd still want a gentoo centric solution. hth, James
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 10:11 PM, Caveman Al Toraboran wrote: not a major point but just to clarify a thing. i think it's unfair to look at SMTP as a single thing that compares against HTTP*. because while HTTP* is a single-ish thing, SMTP is several things. i.e. SMTP is at least 2 parts: Fair point. As I see it, we have two things; 1) what is transferred (email message) and 2) how it is transferred (SMTP, UUCP, etc.). 1. resource exchange layer where people are defined as some kind of URL (e.g. n...@dom.zone) and attachments are base64-ed text balls referred to by some numbers in RFC822. That sounds like the "what is transferred" to me. As in the opaque value of the sender / recipient / body / attachments. It does not matter what the contents of those opaque values are. They make up what is transferred. This part overlaps with HTTP*. let's call this "RESXCH_SERVER". HTTP(S) can overlap with the "how" part of the transfer. But I believe that the HTTP(S) "how" part is independent of the opaque blob part of "what". 2. the part where it defines how to process the exchanged resources (e.g. safe storage, routing, etc). this part is beyond HTTP*'s scope, and is the "web app" scope. let's call this "RESUSE_SERVER" Okay. of course, email still doesn't work with those 2 parts, because you need a way to get mails to your email client, so you end up using POP or IMAP. now, this --itself-- is also two parts: That is highly dependent on your email client. Many traditional Unix email clients read email directly off the file system of the email server. In fact, most POP3(S) and IMAP(S) implementations read the same data off of the email server. The only difference being that the allow the email client to be remote from the email server. I'd like to point out that thus far this thread has been about how to get email between email servers. As such, I think client access protocols are somewhat outside of the existing scope. 1. resource exchange layer to send resources to users. which also overlaps with HTTP* (again). let's call this "RESXCH_CLIENT". The "how". 2. the part where it defines how the mail client to treat the resources. let's call this "RESUSE_CLIENT". See above comment about scope. This is also a "how". But "how" clients get email from servers is decidedly different than "how" servers exchange email. They can both use any underlying transport, be it TCP (like POP3 & IMAP) or HTTP(S). i disagree. i think this is more like it about the current email system: RESXCH_SERVER / RESUSE_SERVER / RESXCH_CLIENT / RESUSE_CLIENT I'm having trouble unpacking that. So I'll provide my version of what I think you're trying to say. Since all of this rides on top of TCP, I'm not going to call it out. 1) The sender (who-sender) sends their email (what) to their outbound email server (who-recipient) with SMTP (how). 2) (The sender's) outbound server (who-sender) sends (the sender's) email (what) to the (the recipient's) inbound server (who-recipient) with SMTP (how). 3) The recipient (who-recipient) pulls email (what) from their inbound server (who-sender) with POP3S / IMAPS (how). Notice how we have a what, who-sender, who-recipient, and how in each of these. The who-sender and who-recipient are the parties of each discrete conversation; 1, 2, or 3. Notice how the what (email) is an opaque blob on each leg of the transmission journey. There are four distinct points with three distinct paths in between. A) [1]---(SMTP)---[2]---(SMTP)---[3]---(POP3S/IMAPS)---[4] 1) Person sending the email. 2) #1's email server. 4) Person receiving the email. 3) #4's email server. (Yes I know those are not in numerical order. #3 and #4 are in dependency order.) The only way to remove a point and transmission path from this process end-to-end process is for #2 and #3 to be the same. B) [1]---(SMTP)---[2/3]---(POP3S/IMAPS)---[4] Other than mega email providers; Google, Microsoft, Yahoo, et al., you are going to have scenario A above. Each step of the way you have what is transferred (the message) and how it is transferred (the protocol) between two points. The what (email) is still an opaque blob on each leg of the transfer. it's 4 different layers to exchange mail between people. We apparently aren't using layers the same way. You seem to be using layers in place of hops. That is both inaccurate and unfair for a number of reasons. There can be any number of additional hops in between # 2 & 3 above for any number of reasons; legal, technical, political, etc. but if we plug HTTP* in the mix, it because only 3 different layers: HTTP* / RESUSE_SERVER / HTTP* / RESUSE_CLIENT You also seem to be describing scenario B above. Here is a variation on scenario A above that is completely realistic if not probable. C) [1]---(SMTP)---[2]---(SMTP)---[3]---(SMTP)---[4]---(SMTP)---[5]---(SMTP)---[6]---(POP3S/IMAPS)---[7] 1) The
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Wed, Aug 26, 2020 at 2:51 PM Grant Taylor wrote: > > On 8/21/20 5:58 PM, Rich Freeman wrote: > > It is what just about every other modern application in existence uses. > > VoIP does not. Yes, but VoIP isn't just implementing a simple data-exchange API. It is a streaming protocol. > No RDBMSs that I'm aware of use it as their primary protocol. (Some may > be able to use HTTP(S) as an alternative.) These pre-date webservices in general. They aren't modern. > Outlook to Exchange does (did?) not use it. Again, not modern. > I'm not aware of any self hosted enterprise grade remote desktop > solution that uses HTTP(S) as it's native transport. Also streaming. > > DNSSEC is: > > > > 1. Still poorly supported even where it makes sense. > > Yet another example of ignorance and / or laziness. > > I have found DNSSEC to be relatively easy to implement, and trivial to > enable on my recursive resolvers. > > The ignorance portion is relatively easy to resolve if people want to. > I highly recommend DNSSEC Mastery by Michael W. Lucas. That $20 (?) > book and moderate amounts of motivation is all anybody that wants to > implement DNSSEC /needs/. Well, maybe check back when you get everybody who sends email to read that book. You can start with my mother. -- Rich
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 5:58 PM, Rich Freeman wrote: It is what just about every other modern application in existence uses. VoIP does not. No RDBMSs that I'm aware of use it as their primary protocol. (Some may be able to use HTTP(S) as an alternative.) Outlook to Exchange does (did?) not use it. It does have a sub-optimal RPC-over-HTTP(S) option for things like mobile clients. But you still get much better service using native non-HTTP(S) protocols. I'm not aware of any self hosted enterprise grade remote desktop solution that uses HTTP(S) as it's native transport. Just because it's possible to force something to use HTTP(S) does not mean that it's a good idea to do so. 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. Probably. And they don't work for anything OTHER than SMTP. There are /other/ libraries that work for /other/ things. Having a general thing that can be abused for almost all things is seldom, if ever, the optimal way to achieve the goal. A library for JSON/webservices/whatever works for half the applications being written today. I choose to believe that even that 50% is significantly sub-optimal and that they have been pressed into that role for questionable reasons. This is simple. This is how just about EVERYBODY does it these days. I disagree. Yes, a lot of people do. But I think it's still a far cry from "just about everybody". http works as a transport mechanism. Simply working is not always enough. Dial up modems "worked" in that data was transferred between two endpoints. Yet we aren't using them today. Frequently, we want optimal or at least the best solution that we can get. 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 think that you are closer than you realize or may be comfortable with. "somebody else figured out" meaning that "someone else has already done the work or the hard part". Meaning that it's possible to ride people's coat tails. HTTP(S) as a protocol has some very specific semantics that make it far from ideal for many things. Things like the server initiating traffic to clients. Some, if not many, of these semantics impose artificial limitations on services. I mean, why use TCP? For starters, TCP ensures that your data arrives at the other end (or notifies you if it doesn't), that it's in order, and that it's not duplicated. There are multiple other protocols that you can use. UDP is a prominent one. Why not use something more tailored to email? Now you're comparing an application layer protocol (email(SMTP)) to a network transport protocol (TCP / UDP / etc.). What transport layer protocol would you suggest using? Be careful to trace higher layer abstraction protocols, e.g. QUIC, back down to the transport layer protocol (UDP in QUIC's case). TCP probably has a dozen optional features that nobody uses with email, so why implement all that just to send email? What contemporary operating system does not have a TCP/IP stack already? How are applications on said operating system speaking traditional / non-QUIC based HTTP(S) /without/ TCP? Even exclusively relying on QUIC still uses UDP. The answer is that it makes WAY more sense to recycle a standard protocol than to invent one. You're still inventing a protocol. It's just at a higher layer. You still have to have some way / method / rules / dialect, more commonly known as a protocol, on whatever communications transport you use. Even your web based application needs to know how to communicate different things about what it's doing. Is it specifying the sender or the recipient or the subject or something else. Protocols are what define that. They are going to exist. It's just a question of where they exist. You're still inventing a protocol. Do you want your protocol to run on top of a taller more complex stack of dependencies? Or would you prefer a shorter simpler stack of dependencies? You're still inventing a protocol. You're just choosing where to put it. And you seem to be in favor of the taller more complex stack. Conversely I am in favor of the shorter simpler stack. 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. No. /I/ would not. HTTP(S) is inherently good at /retrieving/ data. We have used and abused HTTP(S) to make it push data. Depending what the data was and the interactive nature of it, I would consider a bulk file transfer protocol FTPS / SFTP / SCP or even NAS protocols. Things that are well understood and well tested. If I had some reason that they couldn't do what I needed or as efficiently as I needed, I would develop my own protocol. I would certainly do it on top of a transport protocol that ensured my data
Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)
On Wed, Aug 26, 2020 at 05:19:16PM +, Caveman Al Toraboran wrote: > hi. i request comments on this new mail protocol > which i plan to implement some day if things turn > out well. here is its zeroth draft: > > https://github.com/al-caveman/hillarymail Interesting proposal. A few non-technical questions: Why the name "HillaryMail", and why does the logo contain a picture of Margaret Thatcher? ;-) More seriously, do you intend to write a reference implementation, or submit this as a more formal R.F.C. in the event of it attracting more attention? Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the best way of attaining support; I must admit, I have never seen that in an initial protocol proposal. I'm also slightly confused regarding the "goals" section. By "easy to install/use", do you mean "easy" for the people implementing the protocol, or the people making use of said implementations? "Traditional" SMTP mail clients have always been pretty straight-forward for me, although the difficulty involved in _implementing_ an M.T.A. is another story. I find this point rather equivocal. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/21/20 10:15 PM, Caveman Al Toraboran wrote: just to double check i got you right. due to flushing the buffer to disk, this would mean that mail's throughput is limited by disk i/o? Yes. This speed limitation is viewed as a necessary limitation for the safety of email passing through the system. Nothing states that it must be a single disk (block device). It's entirely possible that a fancy MTA can rotate through many disks (block devices), using a different one for each SMTP connection. Thus in theory allowing some to operate in close lock step with each other without depending on / being blocked by any given disk (block device). Thank you for the detailed explanation Ashley. or did i misunderstand? You understand correctly. i sort of feel it may suffice to only save to disk, and close fd. then let the kernel choose when to actually store it in disk. As Ashley explained, some MTAs trust the kernel. I've heard of others issuing a sync after the write. But that is up to each MTA's developers. They have all taken reasonable steps to ensure the safety of email. Some have taken more-than-reasonable steps. -- Grant. . . . unix || die
