Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
> So you want to change from a ubiquitous protocol that is supported by > many Many MANY devices to niche protocol that has a non-trivial > installation / configuration curve. 1st half is "yes", 2nd half is "no" (mine is simpler). > > then, verify messages by mailing their supplied email a confirmation > > message. > > And then you want to take what people send you, turn around and send > unsolicited messages based on it — this is the icing on the cake — using > the protocol that you are trying to avoid. > > It's only a matter of time before someone uses your Tor hidden service > as a vector to send spam. — Joe Job comes to mind. this was just a quick thought. maybe adding a captcha is enough in the contact-us html submission form. this is not a permanent element. just a temporary solution to get messages from the lagging wold. > > redundant as in containing concepts already done in other protocols, > > so smtp has many re-invented wheels that are already invented in > > existing protocols. > > Please elaborate. Please be careful to provide information about /when/ > the protocols that SMTP is supposedly redundant of were developed. > > I suspect that you will quickly find that SMTP predates the protocols > that you are stating it's redundant of. I further suspect that you will > find that SMTP predates them by 10, or more likely 20, if not 30 years. > > Here's a hint. SMTP was ~82. HTTP (1.0) was ~89. We couldn't post > thing in HTTP 1.0. HTTP 2.0 was ~15. sure, smtp is older, but protocol age is irrelevant. right now http/2 is more developed and much more efficient (e.g. compressed binary, pipelining, single connection multiplexing, encryption by default). even http1.4 was a more efficient replacement. > > imo, smtp should be a much-higher level protocol defined purely on > > top of how dns and http/2. > > How do you get any higher layer than the application layer? it's a matter of definition. if we define http/2 as an application layer protocol, and we define "depends on" as "on layer below", then mail is necessarily above the application layer. anyway, this whole osi/internet model is not accurate and many protocols ignore it. i propose this model (fireball model?): 6. app layer(usual drill..) 5. resource layer (exch. by res.; http/2) 4. socket layer (socke ids; tcp/udp/etc ports) 3. end-to-end layer (inter-lan; e.g. ip) 2. hop layer(intra-lan; e.g. mac addr.) 1. physical layer (electromagnetic fluctuations) http/2 is morphing into general "resource layer" where data is exchanged between difference resources. email is just a special case of this inter-resource communication where some resources are humans. > > e.g. for mail submission, there is no need for a separate > > application-layer protocol as we can simply use http/2. because the > > concept of mail submission is a special case of data submission, > > which is already in http/2. > > HTTP /now/ has a way to submit data. HTTP didn't exist when SMTP was > developed. Further, HTTP didn't have the ability to submit data for a > while. true, but that's history. now http/2 is better for resource exchange than smtp. > If you look at multiple layers of the network stack, HTTP and SMTP are > both at the application layer. Now you are suggesting moving equal > peers so that mail is subservient of / dependent on web? yes. > Does HTTP or the web servers have the ability to queue messages to send > between systems? How many web servers handle routing of incoming > messages to send to other servers? How dynamic is this web server > configuration to allow servers for two people who have never exchanged > email to do so? > > This routing, queuing, and many more features are baked into the email > ecosystem. Features that I find decidedly lacking in the web ecosystem. of course. it's called web application; it can do all fancy queueing and routing you want. basically the only part of current "email system" that is not redundant is the part where it is a "mail web app". every other part (e.g. protocol for data exchange) is redundant and inferior to what exists (e.g. http/2). i am considering to make an uwsgi ptyhon script for my personal use. there is absolutely nothing really challenging about the concept of mail routing and queueing. > > here is a more complete example of what i mean: > > > > 1. we lookup MX records to identify smtp servers to submit mails to. > > 2. from the response to that lookup we get a domain name, say, > > mail.dom.com. > > #1 and 2 are par for what we have today. No improvement. yes. dns is ok for now. i never said dns is redundant. > > 3. then, the standard defines a http/2 request format to submit > > the mail. > > Given how things never die on the Internet, you're going to need both > SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive > email with people on the Internet. no, but that's how most of today's mail servers are. e.g. they
[gentoo-user] Time to switch back to AMD?
For several decades, I was a loyal AMD customer. But the last time I upgraded my home desktop (2013), AMD just didn't seem to have anything that could complete with the Core-i3/5 CPUs with integrated graphics. The Intel HD-2500 GPU was plenty fast enough for everything I did back then, so I went with an i3-3220T (2 cores, 4 threads), and have been very happy with it (except for the security vulnerabilties). It even handled it fine when I started working from home and added a second monitor. But, after the last update to the Heli-X flight simulator, I did notice that I'm bouncing off the rev-limiter on the GPU. In order to get a reasonable frame rate and sort-of-smooth background panning I had to dial-down or turn off all the configurable graphics features (anti-aliasing, smoke, reflections, etc.). Even with all of the fancy stuff turned off, it still sometimes struggles and the frame rate drops to below 20. I thought about buying a video card. A $40-50 Radeon or NVidia card would be more than enough GPU. In the past I've been burned by ATI cards being abandoned within a year or two of purcase. Is AMD any better about support? Of course, dealing with closed-source NVidia drivers is also annoying. Also, the motherboard/CPU are almost 8 years old. Maybe it's time for a new AMD Ryzen with an integrated GPU. Even the low-end sub-$100 Ryzen 3 with Vega 8 GPU would be a big jump in performance from the current Intel HD 2500. For another $40, a Ryzen 5 with Vega 11 GPU would completely outclass what I have now. How are the AMD "Wraith Stealth" fans? I've been using the fan that came with the old Core-i3, and it gets a little annoying when it's time to compile chromium (or when flying planes/helicopters). Any issues with Gentoo and Xorg on AMD integrated Vega 8/11 GPUs? AFAICT, the drivers are all open source, and it ought to "just work" with recent kernels. Unfortunately, the capaciters on the existing motherboard are all solid and probably aren't going to pop any time soon.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/18/20 4:25 PM, james wrote: I find all of this *fascinating*. ;-) So I have threads from 7/28 and others that attempt to discover the (gentoo) packages necessary to run my own email services. I have (2) R.Pi4 (8Gram) and (2) more on order to build out complete mail/DNS/security for a small/moderate number of folks to use. Just me to start/test/debug. I expect that, other than CPU speed, the four systems that you have are probably overkill. The CPUs may, or may not, be slow depending on the number of messages you want to handle a day. They are probably quite adequate to start with for personal email. I'd like to build out Grant(Taylor) and Ashley's solution for further learning and testing, on Rpi4 based gentoo systems. robust security and reasonable straightforward (gentoo) admin, is my goal. Sorry to be pedantic, but please list out what you mean by "robust security". I ask more as an exercise for you to think about, and — more importantly — document goals that you'd like to achieve. This documentation may seem somewhat silly, but as has been mentioned multiple times in this thread, there are a LOT of options. So, documenting your desires helps reduce compatible options and makes some choices for you. Don't worry if you find that your previous choice limits you. That will happen. You then need to decide if you want to live with the choice -or- go back a few steps and change your choice. Note: Changing your choice is perfectly fine. Call it what it is, a change, and deal with it. The documentation you're creating is sort of a proto / alpha checklist of goals that you want to achieve. Can either or both of you concisely list what I'd need (the ebuild list) to implement a basic, but complete, secure email system, as delineated in your recent posts? I'd be willing to document both the build and running tests, for the greater good of the gentoo community. I will have to collect a list and get back to you. Note: My list will be biased towards my choices. Given that I do things differently than many email admins, my list is likely to be considerably different than others. If there is interests in the tests and results. I think that quality documentation is always a laudable goal. Remember, I started this some months ago, cause Frontier does not even offer basic email services. I hate all thing cloud (deep desire to be 100% independent of the cloud) and want the ability to remotely retrieve mails and send emails through *my email systems*. I am certainly not alone, as some have sent me private email, with similar desires. Fair enough. The big corporations are trying to destroy and remove standards based email from the internet. I haven't seen much where the big players are trying to actively destroy standards based protocols. I have seen where the big players are requiring higher and higher standards than they did 5 / 10 / 15 years ago. Note: This is neither breaking nor removing standards. If anything, it's adding new public standards and making people adhere to them. Analogy: Some states in the U.S.A. aren't removing old vehicles from the road. They are however introducing requirements for vehicles to adhere to more strict emission standards -or- register as historic vehicles which imposes some restrictions. For me, it is my most useful, important and most desired feature of the internet. I find email (SMTP(S) & IMAPS) and Usenet news (NNTP(S)) to be two of the most critical Internet services to me. The web (HTTP(S)) is extremely convenient. But I could live without the web, admittedly reluctantly. I'm ordering up (6) static IPs from Frontier. Will this be an 8-block (/29) of globally routed IPs? Or is it going to be 6 random IPs in a larger co-mingled IP network? Start inquiring of Frontier about how to configure Reverse DNS. Chances are good that Frontier will be familiar with RFC 2317 — Classless IN-ADDR.ARPA delegation. — If you're not familiar with it, I suggest you read RFC 2317. I'd also suggest starting inquiries of Frontier if they Shared Whois Project (SWIP) and / or RWhois. — My VPS provider doesn't offer SWIP or RWhois, and I wish that they did. — SWIP and / or RWhois are quite nice to have when it comes to making your IP(s) / block(s) stand out from other IP(s) / block(s) near yours. (Think in the same /24). Note: Many things on the Internet prefer for name servers to be in different /24 networks. So, having multiple on different IPs in the same /24 doesn't count to many people. At some point, I'll put another primary bandwidth provider under this, I would encourage you to start with a bandwidth provider that you plan to stick with for a number of years. (I know, things change. Do the best you can with the information you have at hand now, and deal with change if / when it comes.) I say this because it takes a fair bit of effort to turn up a mail
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/18/20 4:36 PM, Grant Taylor wrote: On 8/18/20 5:59 AM, Caveman Al Toraboran wrote: redundant as in containing concepts already done in other protocols, so smtp has many re-invented wheels that are already invented in existing protocols. Please elaborate.� Please be careful to provide information about /when/ the protocols that SMTP is supposedly redundant of were developed. I suspect that you will quickly find that SMTP predates the protocols that you are stating it's redundant of.� I further suspect that you will find that SMTP predates them by 10, or more likely 20, if not 30 years. Here's a hint.� SMTP was ~82.� HTTP (1.0) was ~89.� We couldn't post thing in HTTP 1.0.� HTTP 2.0 was ~15. basically smtp, as an application-layer protocol, is needless. We are all entitled to our own opinion. imo, smtp should be a much-higher level protocol defined purely on top of how dns and http/2. How do you get any higher layer than the application layer? e.g. for mail submission, there is no need for a separate application-layer protocol as we can simply use http/2.� because the concept of mail submission is a special case of data submission, which is already in http/2. HTTP /now/ has a way to submit data.� HTTP didn't exist when SMTP was developed.� Further, HTTP didn't have the ability to submit data for a while. If you look at multiple layers of the network stack, HTTP and SMTP are both at the application layer.� Now you are suggesting moving equal peers so that mail is subservient of / dependent on web? Does HTTP or the web servers have the ability to queue messages to send between systems?� How many web servers handle routing of incoming messages to send to other servers?� How dynamic is this web server configuration to allow servers for two people who have never exchanged email to do so? This routing, queuing, and many more features are baked into the email ecosystem.� Features that I find decidedly lacking in the web ecosystem. here is a more complete example of what i mean: 1. we lookup MX records to identify smtp servers to submit mails to. 2. from the response to that lookup we get a domain name, say, mail.dom.com. #1 and 2 are par for what we have today.� No improvement. 3. then, the standard defines a http/2 request format to submit the mail. Given how things never die on the Internet, you're going to need both SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive email with people on the Internet. So you now have a HUGE net negative in that you have the existing service plus a new service.� You're in many ways doubling the exposure and security risk of email servers. an example of step (3) could be this: ���� https://mail.dom.com/from=...&to=...&cc=...\ ���� &bcc=...&subject=...&attach1=...&attach2=...\ ���� &attachn=... If you were to do this, you would NOT do it via GETs with URL parameters.� You would do it as POSTs. You will also have to find a way to deal with all the aspects of SMTP and RFC 822 email + mime.� I suspect that you will find this to be extremely tricky.� Especially if you try to avoid SMTP / RFC 822 semantics b/c SMTP is apparently a bad thing. How does your example scheme account for the fact that the SMTP envelope from address frequently diff from the RFC 822 From: header?� Remember, this very feature is used thousands of times per day.� So you have to have it. There's also many Many MANY other features of SMTP that are also used thousands of times a day that I'm seeing no evidence of. ���� i don't know how http/2 works.� do they have ���� POST requests?� if so maybe fields attach1, ���� attach2, ..., attachn can be submitted as file ���� uploads using POST. further, if we modify steps (1) and (2), we can generalise this concept into tor services.� e.g.� an email address simply becomes an onion address.� e.g. if vagzgdrh747aei0q.onion is the hidden service address of your mail server, then your email address could be written as (for convenience): ���� remco@vagzgdrh747aei0q.onion I ... I don't have the words.� Go run that idea past an SEO expert. Go ask people to drop their domain name in favor of a hash. I'm not going to hold my breath. How are you going to handle the billions of email clients that exist today, many of which will never be updated, to handle ToR?� You're going to have to have something to gateway old and new. That means that you're still going to have steps #1 and #2.� You can't get away from them without everybody and everything migrating to the new system.� Even then, chances are still extremely good that you're /still/ going to have #2. and when a "mail" client tries to submit you an email, it submits it by this url: ���� https://vagzgdrh747aei0q.onion/to=remco&...etc. I haven't the words. then, in order t
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/18/20 4:30 AM, Ashley Dixon wrote: but nothing can replace it in terms of interoperability and convenience. That is an EXTREMELY important point. SMTP is a protocol that completely independent implementations can use to exchange messages with each other. You can set up gateways to enable different forms of messages to go to and come from SMTP. Things like this allow you to send a fax to an email gateway to an MMS gateway to receive a picture on your phone. There are /SO/ /MANY/ to / from email gateways (which effectively means SMTP) that are used each and every day to run the world. Perhaps the younger generation ... would almost-unanimously disagree, but your proposed solution doesn't really provide greater ease for you, or the people e-mailing you! mail(fire)ball provides something, but I'm quite sure "ease (of use)" is decidedly /NOT/ one of the things that it provides. -- 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 5:59 AM, Caveman Al Toraboran wrote: redundant as in containing concepts already done in other protocols, so smtp has many re-invented wheels that are already invented in existing protocols. Please elaborate. Please be careful to provide information about /when/ the protocols that SMTP is supposedly redundant of were developed. I suspect that you will quickly find that SMTP predates the protocols that you are stating it's redundant of. I further suspect that you will find that SMTP predates them by 10, or more likely 20, if not 30 years. Here's a hint. SMTP was ~82. HTTP (1.0) was ~89. We couldn't post thing in HTTP 1.0. HTTP 2.0 was ~15. basically smtp, as an application-layer protocol, is needless. We are all entitled to our own opinion. imo, smtp should be a much-higher level protocol defined purely on top of how dns and http/2. How do you get any higher layer than the application layer? e.g. for mail submission, there is no need for a separate application-layer protocol as we can simply use http/2. because the concept of mail submission is a special case of data submission, which is already in http/2. HTTP /now/ has a way to submit data. HTTP didn't exist when SMTP was developed. Further, HTTP didn't have the ability to submit data for a while. If you look at multiple layers of the network stack, HTTP and SMTP are both at the application layer. Now you are suggesting moving equal peers so that mail is subservient of / dependent on web? Does HTTP or the web servers have the ability to queue messages to send between systems? How many web servers handle routing of incoming messages to send to other servers? How dynamic is this web server configuration to allow servers for two people who have never exchanged email to do so? This routing, queuing, and many more features are baked into the email ecosystem. Features that I find decidedly lacking in the web ecosystem. here is a more complete example of what i mean: 1. we lookup MX records to identify smtp servers to submit mails to. 2. from the response to that lookup we get a domain name, say, mail.dom.com. #1 and 2 are par for what we have today. No improvement. 3. then, the standard defines a http/2 request format to submit the mail. Given how things never die on the Internet, you're going to need both SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive email with people on the Internet. So you now have a HUGE net negative in that you have the existing service plus a new service. You're in many ways doubling the exposure and security risk of email servers. an example of step (3) could be this: https://mail.dom.com/from=...&to=...&cc=...\ &bcc=...&subject=...&attach1=...&attach2=...\ &attachn=... If you were to do this, you would NOT do it via GETs with URL parameters. You would do it as POSTs. You will also have to find a way to deal with all the aspects of SMTP and RFC 822 email + mime. I suspect that you will find this to be extremely tricky. Especially if you try to avoid SMTP / RFC 822 semantics b/c SMTP is apparently a bad thing. How does your example scheme account for the fact that the SMTP envelope from address frequently diff from the RFC 822 From: header? Remember, this very feature is used thousands of times per day. So you have to have it. There's also many Many MANY other features of SMTP that are also used thousands of times a day that I'm seeing no evidence of. i don't know how http/2 works. do they have POST requests? if so maybe fields attach1, attach2, ..., attachn can be submitted as file uploads using POST. further, if we modify steps (1) and (2), we can generalise this concept into tor services. e.g. an email address simply becomes an onion address. e.g. if vagzgdrh747aei0q.onion is the hidden service address of your mail server, then your email address could be written as (for convenience): remco@vagzgdrh747aei0q.onion I ... I don't have the words. Go run that idea past an SEO expert. Go ask people to drop their domain name in favor of a hash. I'm not going to hold my breath. How are you going to handle the billions of email clients that exist today, many of which will never be updated, to handle ToR? You're going to have to have something to gateway old and new. That means that you're still going to have steps #1 and #2. You can't get away from them without everybody and everything migrating to the new system. Even then, chances are still extremely good that you're /still/ going to have #2. and when a "mail" client tries to submit you an email, it submits it by this url: https://vagzgdrh747aei0q.onion/to=remco&...etc. I haven't the words. then, in order to authenticate a source, we simply use public-private keys ... Because that has worked out so well and with so few problems in the past 25 years. ... to sign messag
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 8/18/20 1:00 AM, Caveman Al Toraboran wrote: not specifically with a mail provider, but with other i.t. services, yes. and since they're all humans, then the simplest model that explains this is that this is about humans in general, and same past experience would extend to mail provider's admins. To each their own. yes. smtp is nasty, and also redundant. I disagree. Simple Mail Transfer /Protocol/, as in the application layer language spoken between mail servers is fairly elegant. What is done on top of that and with the data that goes back and forth is far more iffy. I also disagree that SMTP is redundant. I'm not aware of anything else nearly as ubiquitous as SMTP for getting messages between systems in a fault tolerant manner. makes me wonder if i should just create me a hidden tor service that is just a normal website, and give its url to people (instead of email) who want to message me by telling them ``submit your messages to me''. So you want to change from a ubiquitous protocol that is supported by many Many MANY devices to niche protocol that has a non-trivial installation / configuration curve. then, verify messages by mailing their supplied email a confirmation message. And then you want to take what people send you, turn around and send unsolicited messages based on it — this is the icing on the cake — using the protocol that you are trying to avoid. It's only a matter of time before someone uses your Tor hidden service as a vector to send spam. — Joe Job comes to mind. -- 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 12:43 AM, Caveman Al Toraboran wrote: would i get blacklisted for simply not using spf/dkim/etc? even if no other user is using the mail service other than me and i'm not mass mailing? I don't think it's that you would be black listed per say. Rather, I think it's that nothing would cause your email to stand out / up and appear more legitimate than the general background noise. You want to stand out from the background noise so that you aren't subject to the almost default block of a lot of background noise. It also provides something for positive (and negative) reputation to be associated with. Think "some random person said" vs "Caveman said". Which will mean more in the circles you travel in? -- Grant. . . . unix || die
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Tuesday, August 18, 2020 2:21 PM, Remco Rijnders wrote: > On Tue, Aug 18, 2020 at 07:00:52AM +, Caveman wrote in > > > yes. smtp is nasty, and also redundant. > > How is it redundant? redundant as in containing concepts already done in other protocols, so smtp has many re-invented wheels that are already invented in existing protocols. basically smtp, as an application-layer protocol, is needless. imo, smtp should be a much-higher level protocol defined purely on top of how dns and http/2. e.g. for mail submission, there is no need for a separate application-layer protocol as we can simply use http/2. because the concept of mail submission is a special case of data submission, which is already in http/2. here is a more complete example of what i mean: 1. we lookup MX records to identify smtp servers to submit mails to. 2. from the response to that lookup we get a domain name, say, mail.dom.com. 3. then, the standard defines a http/2 request format to submit the mail. an example of step (3) could be this: https://mail.dom.com/from=...&to=...&cc=...\ &bcc=...&subject=...&attach1=...&attach2=...\ &attachn=... i don't know how http/2 works. do they have POST requests? if so maybe fields attach1, attach2, ..., attachn can be submitted as file uploads using POST. further, if we modify steps (1) and (2), we can generalise this concept into tor services. e.g. an email address simply becomes an onion address. e.g. if vagzgdrh747aei0q.onion is the hidden service address of your mail server, then your email address could be written as (for convenience): remco@vagzgdrh747aei0q.onion and when a "mail" client tries to submit you an email, it submits it by this url: https://vagzgdrh747aei0q.onion/to=remco&...etc. then, in order to authenticate a source, we simply use public-private keys to sign messages. basically, our public keys become our user identifiers. this will also solve the problem of the case when an onion address changes. i call this protocol mailball for the purpose of making speech this mail thread a bit easier. of course, we can pick better names, and refine the mechanics. > > makes me wonder if i should just create me a > > hidden tor service that is just a normal website, > > and give its url to people (instead of email) who > > want to message me by telling them ``submit your > > messages to me''. then, verify messages by > > mailing their supplied email a confirmation > > message. > > Ah, the "Don't spam us, we'll spam you approach?" for people who use the deprecated smtp protocol, yes, it will be "don't spam us, we'll spam you". however, that's not our fault. they are using a deprecated protocol, and we are just kind enough to allow them an opportunity to talk to us over the superior mailball protocol. basically, they are using deprecated identifiers (email ids) instead of public keys, and we're kind enough to give them a temporary api so that we confirm their emails. on the other hand, people who use mailball will not have this problem. why? because ids are public keys anyway, and their messages are signed by their private keys (the usual drill, won't insult your intelligence).
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On 18-Aug-20 8:43, Caveman Al Toraboran wrote: would i get blacklisted for simply not using spf/dkim/etc? even if no other user is using the mail service other than me and i'm not mass mailing? Well, hear my story: I too was running simple mail-server. Just a few users I trust, no public relaying, so what could possibly go wrong? As it turned out later: everything! For a few months all was running as expected, but then some time later all valid email sent by my mail-server was suddenly flagged as spam and rejected. It took me some time to investigate but finally I found my domain (not IP) was on Spamhaus' DBL (domain block list). How did it get there? It seems that someone has created faked spf-record for my domain (I was not using dnssec at that time) and somehow spread it out (maybe using dns cache-poisoning?) to many public dn-resolvers. With that spf-record he authorised many spam-sending hosts to send email with sender field pointing to my domain. And that was even bigger problem, because one can easily switch to different vps/IP if it gets blacklisted, but I did not want to abandon my domain. It took me quite long time to fix everything. So short answer is yes! Even if you are not mass-mailing, you can still get blacklisted, if you do not secure your IP, domain and mail-server properly... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user]
Caveman Al Toraboran wrote: > ‐‐‐ Original Message ‐‐‐ > On Monday, August 17, 2020 8:54 PM, Dale wrote: > >> If you visit this site, it doesn't allow adblock to be in use. I can't tell >> if it has the actual list or not. Sites that don't like my adblock blocking >> their annoying ads that I will never click on gets a tab closure. I've >> never once clicked on a ad or any sponsored link even in google search >> results. Link may work for you, may not. >> >> https://www.businessinsider.com/nsa-prism-keywords-for-domestic-spying-2013-6 >> >> These sites I can see the list. The more obvious ones are further down the >> list. >> >> https://www.sovereignman.com/lifestyle-design/uncle-sam-admits-monitoring-you-for-these-377-words-6832/ >> >> https://www.forbes.com/sites/reuvencohen/2012/05/26/department-of-homeland-security-forced-to-release-list-of-keywords-used-to-monitor-social-networking-sites/ > i like how terrorists speak only english. > > rgrds, > cm > I'm sure they search in several languages depending on what Govt it is. I'm sure that list varies too. To be fair tho, if they put the list in another language, it wouldn't do me any good since I can only *read* English. I'm sure I'm not alone in that too. ;-) Dale :-) :-)
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Tue, Aug 18, 2020 at 2:43 AM Caveman Al Toraboran wrote: > ‐‐‐ Original Message ‐‐‐ > On Monday, August 17, 2020 3:48 PM, Jarry wrote: > > > Rent VPS and be your own admin. But running properly configured > > mail-server is not so easy. Setting up postfix/exim/sendmail > > is just a beginning. If you mean it seriously and do not want > > your IP to land on blacklists (and you vps suspended), there is > > much more to do, i.e. spf, dkim, dmarc, dnssec, etc... > > would i get blacklisted for simply not using > spf/dkim/etc? even if no other user is using the > mail service other than me and i'm not mass > mailing? It is up to the individual recipient's email admin, but increasingly the answer is yes. Your biggest issue will be IP reputation, however. IPs that are assigned to consumers are almost always blacklisted regardless of what you're doing on your end, and the're blacklisted before you even attempt to send your first message. Personally I run my own server for reception, but all my outgoing mail either goes through Gmail or Amazon SES, depending on whether Gmail was used as the MUA. Sure, Amazon isn't free, but it is REALLY cheap ($0.10 for 1000 emails, plus $0.12 per GB). I don't send that many emails or much in attachments, so the bill is tiny. Gmail is free and you can send outgoing messages from any email address that you control. Receiving email isn't a big deal though managing spam can be painful. Sending it has become increasingly difficult because of others managing spam, and IMO it isn't worth trying to deal with directly unless you're a large concern. -- Rich
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 8:00 PM, Grant Taylor wrote: > On 8/16/20 10:50 PM, Caveman Al Toraboran wrote: > > 3. vps admin is not trusty and their sys admin may read my emails, > > and laugh at me! > > Do you have any (anecdotal) evidence that this has actually happened? not specifically with a mail provider, but with other i.t. services, yes. and since they're all humans, then the simplest model that explains this is that this is about humans in general, and same past experience would extend to mail provider's admins. > Well, seeing as how you're talking about email, the biggest elephant in > the room is SMTP's default of unencrypted communications path. It's > realtively easy to add support for encryption, but more systems than I'm > comfortable with don't avail themselves of the optional encryption for > some reason. Sure, it's possible to configure many receiving SMTP > servesr to require it from specific sending systems and / or sending > domains. But this is effort you have to expend to enact these restrictions. yes. smtp is nasty, and also redundant. makes me wonder if i should just create me a hidden tor service that is just a normal website, and give its url to people (instead of email) who want to message me by telling them ``submit your messages to me''. then, verify messages by mailing their supplied email a confirmation message.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 3:48 PM, Jarry wrote: > Rent VPS and be your own admin. But running properly configured > mail-server is not so easy. Setting up postfix/exim/sendmail > is just a beginning. If you mean it seriously and do not want > your IP to land on blacklists (and you vps suspended), there is > much more to do, i.e. spf, dkim, dmarc, dnssec, etc... would i get blacklisted for simply not using spf/dkim/etc? even if no other user is using the mail service other than me and i'm not mass mailing?
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 3:33 PM, Ashley Dixon wrote: > How many concurrent users will be connected to the mail server? How much > traffic > will the S.M.T.P. server receive (read: how many e-mails arrive on a daily > basis)? If you really don't trust your V.P.S. provider, and your mail server > is > small-ish, you could just skip all the trust issues and buy a cheap Raspberry > Pi > for £20 or so. 1 user (me). about 2 real daily mails. maybe 10 in peak times. that, plus gentoo's users list, plus spam. but i don't see much spammers in protonmail's spambox. so i guess my spam is low. > Running a mail server over a domestic connection presents some issues, such as > dynamic I.P. ranges appearing in the Spamhaus blocklist, or some > tyrannicalesque > I.S.P.s blocking outbound port 25 (S.M.T.P. submission port), but it is > possible > to have a smooth, self-administered mail server, providing you can put in the > time and effort. I have been doing it myself for a few years with Courier and > Postfix (although I wouldn't recommend Courier; Dovecot is far superior). > > What do you think? interesting. do you have reverse ptr records for your domain name pointing to your home's ip? did you pay extra fees for this ptr to your isp? i wonder if price-wise, and uptime-wise, that would beat a cheap vps at 20 bucks/year.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Tue, Aug 18, 2020 at 07:00:52AM +, Caveman Al Toraboran wrote: > yes. smtp is nasty, and also redundant. S.M.T.P. is extremely well-established, and has always been a reasonably pleasant experience for me. Which part of the protocol makes you think of it as "nasty"? > makes me wonder if i should just create me a > hidden tor service that is just a normal website, > and give its url to people (instead of email) who > want to message me by telling them ``submit your > messages to me''. then, verify messages by > mailing their supplied email a confirmation > message. That doesn't make any sense. Setting up e-mail is a fair challenge, but nothing can replace it in terms of interoperability and convenience. Perhaps the younger generation (of whom I am unfortunately a part) would almost-unanimously disagree, but your proposed solution doesn't really provide greater ease for you, or the people e-mailing you! -- 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 Tue, Aug 18, 2020 at 07:00:52AM +, Caveman wrote in <2gbde2AzVUH4P9HuGPvBvJpZBjaeFBqUfOPfrojvSXcRQgqYcNuLDa0BZbdtS1QrvKymDpPLozphS0JtKDgRXX4WE1rh439hq_VnseMCJZo=@protonmail.com>: yes. smtp is nasty, and also redundant. How is it redundant? makes me wonder if i should just create me a hidden tor service that is just a normal website, and give its url to people (instead of email) who want to message me by telling them ``submit your messages to me''. then, verify messages by mailing their supplied email a confirmation message. Ah, the "Don't spam us, we'll spam you approach?"
Re: [gentoo-user]
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 8:54 PM, Dale wrote: > > If you visit this site, it doesn't allow adblock to be in use. I can't tell > if it has the actual list or not. Sites that don't like my adblock blocking > their annoying ads that I will never click on gets a tab closure. I've never > once clicked on a ad or any sponsored link even in google search results. > Link may work for you, may not. > > https://www.businessinsider.com/nsa-prism-keywords-for-domestic-spying-2013-6 > > These sites I can see the list. The more obvious ones are further down the > list. > > https://www.sovereignman.com/lifestyle-design/uncle-sam-admits-monitoring-you-for-these-377-words-6832/ > > https://www.forbes.com/sites/reuvencohen/2012/05/26/department-of-homeland-security-forced-to-release-list-of-keywords-used-to-monitor-social-networking-sites/ i like how terrorists speak only english. rgrds, cm
