On Sun, Aug 30, 2020 at 06:00:11PM +0100, Wols Lists wrote:
> (I've never seen an smtp:/ or imap:/ url, but I guess they could easily
> be formulated.)
They are sometimes used, usually in addition to a port specifier, in order to
express a protocol univocally. For example, here's part of my Mutt
‐‐‐ Original Message ‐‐‐
On Friday, August 28, 2020 11:27 PM, antlists wrote:
> On 26/08/2020 21:21, Grant Taylor wrote:
>
> > > so basically total expected number of protocols/layers used in the
> > > universe, per second, will be much less if we, on planet earth, use a
> > > mail
On 30/08/20 14:06, Caveman Al Toraboran wrote:
> you know there is this almost neat concept called
> url?
>
> rumours say that urls can identify various web
> applications, ranging from websites, rss, games,
> video, and, guess what? mails. all over
> http/https/h2 over same tcp 80/443. hard
On 2020-08-28 20:29, Grant Taylor wrote:
> On 8/28/20 6:10 PM, Michael Orlitzky wrote:
>> I think I see where we're diverging: I'm assuming that the employees of
>> the VPS provider can hop onto any running system with root privileges.
>
> Perhaps I'm woefully ignorant, but my current working
On 8/28/20 3:54 PM, Poison BL. wrote:
On Mon, Aug 17, 2020 at 12:51 AM Caveman Al Toraboran
wrote:
hi. context:
1. tinfoil hat is on.
2. i feel disrespected when someone does things to
my stuff without getting my approval.
3. vps admin is not trusty and their sys admin may
read my
On 8/28/20 6:10 PM, Michael Orlitzky wrote:
I think I see where we're diverging: I'm assuming that the employees of
the VPS provider can hop onto any running system with root privileges.
Perhaps I'm woefully ignorant, but my current working understanding is
that no virtual machine hypervisor
On 8/28/20 5:00 PM, Grant Taylor wrote:
On 8/28/20 1:18 PM, antlists wrote:
The main reason other applications use "TCP over HTTP(S)" is because
stupid network operators block everything else!
I agree that filtering is a problem.
I also think that it's something that most people can overcome
On 8/28/20 4:45 PM, james wrote:
If we can get these codes running on arm64 (R.P.4) surely running them
on AMD or intel is trivial?
I will be flabbergasted if something would run on the Raspberry Pi that
won't run on x86 (Intel / AMD). Presuming that it's complied from
common source code.
On 2020-08-28 19:43, Grant Taylor wrote:
>
> The only way to get the key is to extract it out of the running VPS's
> memory. Something that I think is beyond the capability of many, but
> definitely not all, people.
>
> ...
>
> As long as STARTTLS is used (and validated) between the MTAs and
On 8/28/20 4:26 PM, Michael Orlitzky wrote:> The contents of the disk
are unencrypted while the server is powered
on, or at least while the server is receiving email (while it's reading
from and writing to that disk). In practice that will be all the time
-- you can't log in and type the
On 8/28/20 4:56 PM, Grant Taylor wrote:
On 8/28/20 1:55 PM, james wrote:
I'm proposing, via a small corp I own, to purchase up to (3) dual
Rasp.pi 4 setups of (2) R.Pi.4 8gig ram setups and send them to the
devs WE all decide on.
A few points.
1)� I don't think that 8 GB of RAM is
On 2020-08-28 17:53, Grant Taylor wrote:
> On 8/28/20 3:33 PM, Michael Orlitzky wrote:
>> TLS only secures the channel; what comes out at the end is a plain-text
>> message that can be read with minimal effort by the VPS provider,
>> no skullduggery needed.
>
> I agree that STARTTLS only
On 8/28/20 3:33 PM, Michael Orlitzky wrote:
TLS only secures the channel; what comes out at the end is a plain-text
message that can be read with minimal effort by the VPS provider,
no skullduggery needed.
I agree that STARTTLS only protects the email while it's in flight
between servers.
On 2020-08-28 17:12, Grant Taylor wrote:
> On 8/28/20 1:54 PM, Poison BL. wrote:
>> I'm rather late to the game with this, but at the end of the day,
>> mail coming *into* a mail server isn't typically encrypted (and even
>> that is only the body, the headers can still reveal a great deal,
>>
On 8/28/20 1:54 PM, Poison BL. wrote:
I'm rather late to the game with this, but at the end of the day,
mail coming *into* a mail server isn't typically encrypted (and even
that is only the body, the headers can still reveal a great deal,
and are necessary for the server to work with it).
james wrote:
> On 8/21/20 4:10 PM, Grant Taylor wrote:
>> 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
On 8/28/20 1:18 PM, antlists wrote:
The main reason other applications use "TCP over HTTP(S)" is because
stupid network operators block everything else!
I agree that filtering is a problem.
I also think that it's something that most people can overcome when they
control the firewall between
On 8/28/20 1:55 PM, james wrote:
I'm proposing, via a small corp I own, to purchase up to (3) dual
Rasp.pi 4 setups of (2) R.Pi.4 8gig ram setups and send them to the
devs WE all decide on.
A few points.
1) I don't think that 8 GB of RAM is required. -- My email server is
a VPS with 2 GB
On 28/08/2020 20:34, J. Roeleveld wrote:
Cheers,
Wol
I think you meant that Caveman doesn't understand what TCP (and UDP) actually
is.
Grant does seem to know what he is talking about.
Sorry yes I did. I got rather confused ... not surprising really :-)
Cheers,
Wol
On 8/21/20 4:10 PM, Grant Taylor wrote:
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
On Mon, Aug 17, 2020 at 12:51 AM Caveman Al Toraboran
wrote:
>
> hi. context:
>
> 1. tinfoil hat is on.
> 2. i feel disrespected when someone does things to
>my stuff without getting my approval.
> 3. vps admin is not trusty and their sys admin may
>read my emails, and laugh at me!
> 4.
On 28 August 2020 21:27:52 CEST, antlists wrote:
>On 26/08/2020 21:21, Grant Taylor wrote:
>>> so basically total expected number of protocols/layers used in the
>>> universe, per second, will be much less if we, on planet earth, use
>a
>>> mail system that uses HTTP* instead of RESXCH_*.
>>
On 26/08/2020 21:21, Grant Taylor wrote:
so basically total expected number of protocols/layers used in the
universe, per second, will be much less if we, on planet earth, use a
mail system that uses HTTP* instead of RESXCH_*.
I obviously disagree.
Exactly. You now need a protocol/layer
On 26/08/2020 19:51, Grant Taylor wrote:
Just because it's possible to force something to use HTTP(S) does not
mean that it's a good idea to do so.
The main reason other applications use "TCP over HTTP(S)" is because
stupid network operators block everything else!
Cheers,
Wol
On 26/08/2020 18:40, Grant Taylor wrote:
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
‐‐‐ Original Message ‐‐‐
On Friday, August 28, 2020 2:35 AM, Ashley Dixon wrote:
> On Thu, Aug 27, 2020 at 09:07:03PM +, Caveman Al Toraboran wrote:
>
> > anyway i'm out of this. massive waste of time. i
> > could've finished server-side hillarymail by it.
>
> Oh, come on. People on
‐‐‐ Original Message ‐‐‐
On Thursday, August 27, 2020 8:15 PM, Grant Taylor
wrote:
> On 8/27/20 7:00 AM, Caveman Al Toraboran wrote:
>
> > but i this way of looking at protocols (despite being common) is wrong.
>
> Why do you think that it is wrong?
>
> What is not factually correct
On Thu, Aug 27, 2020 at 09:07:03PM +, Caveman Al Toraboran wrote:
> anyway i'm out of this. massive waste of time. i
> could've finished server-side hillarymail by it.
Oh, come on. People on this list have decades of experience managing and
implementing e-mail protocols, and you
‐‐‐ Original Message ‐‐‐
On Thursday, August 27, 2020 12:21 AM, Grant Taylor
wrote:
> email emailemail
> SMTP SMTP POP3S/IMAPS
> A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4]
>
> Now what you are proposing:
>
>
On 8/27/20 7:00 AM, Caveman Al Toraboran wrote:
but i this way of looking at protocols (despite being common) is wrong.
Why do you think that it is wrong?
What is not factually correct about it?
i also disagree with the network layering proposed by osi or the
other ones commonly published
On 8/27/20 6:07 AM, Victor Ivanov wrote:
I have been quietly following this discussion and I've seen SRS being
mentioned a number of times.
Welcome to an active part in the conversation. :-)
Now, I know what SRS _does_ (perhaps not fully?) to prevent unintended
rejection by a receiving MTA
On 27/08/2020 02:31, Grant Taylor wrote:
> - SRS (mail-filter/libsrs2) []
> - emerge -a mail-filter/libsrs2
>
I have been quietly following this discussion and I've seen SRS being
mentioned a number of times.
Now, I know what SRS _does_ (perhaps not fully?) to prevent unintended
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.
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.
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
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
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
On Sat, Aug 22, 2020 at 09:17:56PM +0100, Ashley Dixon wrote:
> On Sat, Aug 22, 2020 at 04:15:38AM +, 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?
[...]
> When
On Sat, Aug 22, 2020 at 04:15:38AM +, Caveman Al Toraboran wrote:
> ‐‐‐ Original Message ‐‐‐
> On Saturday, August 22, 2020 12:10 AM, Grant Taylor
> wrote:
>
> > There is some nebulous area around what that actually means. But the
> > idea is that the receiving server believes, in
‐‐‐ Original Message ‐‐‐
On Saturday, August 22, 2020 12:19 AM, Grant Taylor
wrote:
> > 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
‐‐‐ Original Message ‐‐‐
On Saturday, August 22, 2020 12:10 AM, Grant Taylor
wrote:
> 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
‐‐‐ Original Message ‐‐‐
On Friday, August 21, 2020 11:37 PM, Grant Taylor
wrote:
> SMTP may not be the best, but I do think that it has some merits.
> Merits that the previously mentioned HTTP/2 alternative misses.
not a major point but just to clarify a thing.
i think it's unfair to
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
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
‐‐‐ 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
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
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.
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
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-
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
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
>>
‐‐‐ 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
On 19/08/2020 16:19, Caveman Al Toraboran wrote:
‐‐‐ Original Message ‐‐‐
On Wednesday, August 19, 2020 7:10 PM, Grant Taylor
wrote:
Per protocol specification, SMTP is EXTREMELY robust.
It will retry delivery, nominally once an hour, for up to five (or
seven) days. That's 120-168
‐‐‐ Original Message ‐‐‐
On Wednesday, August 19, 2020 7:10 PM, Grant Taylor
wrote:
> Per protocol specification, SMTP is EXTREMELY robust.
>
> It will retry delivery, nominally once an hour, for up to five (or
> seven) days. That's 120-168 delivery attempts.
>
> Further, SMTP
‐‐‐ Original Message ‐‐‐
On Wednesday, August 19, 2020 12:25 PM, Ashley Dixon wrote:
> I don't think you fully understand Grant's point. Whilst HTTP(/2) may be more
> featureful for serving web pages, it makes absolutely no sense to use for
> anything but. Protocol age absolutely is not
First, well said.
On 8/19/20 2:27 AM, Ashley Dixon wrote:
Apologies for my unintended verbosity. My subconscious _really_
wanted to point out that SMTP is (generally) RELIABLE. ;-)
Second, this is an understatement.
Per protocol specification, SMTP is EXTREMELY robust.
It will retry
On Wed, Aug 19, 2020 at 09:25:11AM +0100, Ashley Dixon wrote:
> reliable method of reliably transferring
Apologies for my unintended verbosity. My subconscious _really_ wanted to point
out that SMTP is (generally) RELIABLE. ;-)
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E
On Wed, Aug 19, 2020 at 01:34:46AM +, Caveman Al Toraboran wrote:
> 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
> 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
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
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
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
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
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
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
‐‐‐ 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
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
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
‐‐‐ 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
‐‐‐ 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
‐‐‐ 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
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
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
On 8/17/20 6:10 AM, Wols Lists wrote:
Yup. If you've got mail DNS records pointing at your home server,
incoming mail shouldn't be a problem and your vps admin can't snoop
:-)
True.
But the ISP can still sniff the traffic and you can be subject to DPI.
Can't you tell your server to forward
On 8/17/20 5:33 AM, 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)?
My main VPS has a single digit number of clients and processes anywhere
between
On 8/16/20 10:50 PM, Caveman Al Toraboran wrote:
hi.
Hi
context:
1. tinfoil hat is on.
Okay.
2. i feel disrespected when someone does things to my stuff without
getting my approval.
Sure.
3. vps admin is not trusty and their sys admin may read my emails,
and laugh at me!
Do you
On 17/08/20 12:33, Ashley Dixon wrote:
> On Mon, Aug 17, 2020 at 04:50:43AM +, Caveman Al Toraboran wrote:
>> thoughts on how to maximally satisfy these
>> requirements?
>
> How many concurrent users will be connected to the mail server? How much
> traffic
> will the S.M.T.P. server receive
On 17-Aug-20 6:50, Caveman Al Toraboran wrote:
hi. context:
1. tinfoil hat is on.
2. i feel disrespected when someone does things to
my stuff without getting my approval.
3. vps admin is not trusty and their sys admin may
read my emails, and laugh at me!
4. whole thing is not worth
On Mon, Aug 17, 2020 at 04:50:43AM +, Caveman Al Toraboran wrote:
> thoughts on how to maximally satisfy these
> requirements?
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
hi. context:
1. tinfoil hat is on.
2. i feel disrespected when someone does things to
my stuff without getting my approval.
3. vps admin is not trusty and their sys admin may
read my emails, and laugh at me!
4. whole thing is not worth much money. so not
welling to pay more than the
80 matches
Mail list logo
