On 7/11/23 4:54 AM, Slavko via mailop wrote:
If something have to be said, then it have to be said and then
doesn't matter who said it ;-)
Well said.
Nowaydays (especially joung) people tends to feel as experts, when
they setup something first time. Thus, when not used word by word, it
is good reminder. On other side, i work with computers & networks for
more than 30 years, and still have questions ;-)
:-)
I start to maintain my own mail after 20 years of experiences with
other nerwork services (both, LAN & WAN). Before that i afraid, that
my experiences are not enough to fight with SPAM (in both directions,
incoming & outgoing). But finally i recently (some years) decided to
start with it, thus my point of view is relative fresh.
Fair enough.
Fortunately, with email, especially with a non-high-value domain, can be
relatively safe to start with.
Setup and get it working is not different than other services, not
more easy nor more hard, just different. It requires to learn how to
setup particular SW as in other services.
I suspect that one of the things that makes email harder is that it
encompasses many other interrelated and interdependent things. So if
you're starting from zero there is a lot to learn. Other protocols /
services tend to have less interdependencies.
What i see as more hard with email is:
+ it is not one protocol (SMTP and IMAP/POP)
+ it is not one SMTP purpose (MTA/Submission)
+ terminology is not clear (how many terms eg. for return-path, relay, etc)
+ it is very flexible, choose proper topology is not easy without
some experiences
+ many roles, which one MTA can do
+ too many RFCs describing email, and some of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails
These things make email harder to start, than other services, but
after one got them, it is as easy/hard as any other service.
BTW, what i most afraid (before i start) was how i will fight with
SPAM to (required) postmaster mailbox. But that simple doesn't happen
and that address gots near to no SPAM.
I think my concern back when I started administering email was that my
server didn't become part of the problem / become a source of spam,
relayed email, etc. Functioning as I wanted it was a secondary desire.
Fortunately I think I've manged to do just enough of both for quite a
while now.
Aside: I agree, my RFC mandated accounts get very little spam.
Yes, but will iname it as good practice, not as best.
Fair enough.
I have mixed feel from these. While can be "good friends", it seems
that they involved to "bad boss". I feel, that particular RFCs was
done by people, who consider them as "must have" and thus they
mention cases (eg. DMARCs none policy) in not clear way, and doesn't
describe clearly what to do if not all are implemented (eg. SPF
without DMARC) on receiver side...
I suspect that some of that was on purpose as to not dictate what
recipients should do. After all, your server, your rules.
I think SPF itself is relatively straightforward.
1) A domain owner publishes where they will send email from and what
they would like recipients to do with email that does not match said
publication.
2) A receiving email server uses that published data to influence their
local filtering algorithms.
IMHO DKIM is slightly more complex:
1) A sending server applies a cryptographic attestation of (part of)
the message that it is sending.
2) A receiving email server uses that cryptographic attestation to
influence their local filtering algorithms.
DMARC is more complicated yet in what it checks.
1) A domain owner publishes filtering criteria that they would like
applied to their domain.
2) A receiving email server uses that published data to influence their
local filtering algorithms.
Notice how all three are someone publishing information and someone
(else) using that published information to influence recipient filtering
configuration.
What each filters on and how it does the filtering is different. But at
a basic level, they are all similar two part systems; publish
information and use said information.
That oligarch's behaviour is IMO direct result of aforementioned
"must have" approach.
I'd have to go back and reread the various RFCs, but I don't remember
anywhere in the specification what values should be in what fields, just
that specific fields should be populated. Of course this is predicated
on you wanting to utilize said specification in an interoperable way.
I meet rejects due forward confirmed reverse DNS fails, then i setup
it. But i agree, that mention it as requirements is wrong.
Yes, you will very likely need your forward and reverse DNS to match.
But those values matching has nothing to do with what those values are.
3-2-0-192.CITY.STATE.ISP.EXAMPLE. IN A 192.0.2.3
And
3.2.0.192.in-addr.arpa. IN PTR 3-2-0-192.CITY.STATE.ISP.EXAMPLE.
Are forward confirmed reverse DNS.
I think they are ugly.
But I also think that it would be possible to send email, using
3-2-0-192.CITY.STATE.ISP.EXAMPLE as the hello name to many locations.
Or at least that the name in and of itself is largely immaterial as long
as it doesn't match a pattern that people are filtering out. --
Remember, some people go out of their way to identify what they consider
to be algorithmically generated names.
As long as ISP.EXAMPLE hasn't published the subnet as a range that
shouldn't send mail, then you should be able to make it send email.
I'll wager a cup of coffee that you could even use such a hostname / IP
address to send email to one of the email oligarchs if you adhere to
their other requirements.
I run own LANs MTAs and forwad to ISP's smarthost for years, no IP is
involved, but it is still own email server (including IMAP via
fetchmail).
Inbound from the world and outbound to the world are effectively two
very different services.
Using your ISP as a smart host is, or was, a good way to do this for
many people for many years. Now, things like SPF make this a little bit
more difficult.
That being said, substitute an ESP in place of the ISP and this is
exactly what a LOT of people are still doing today.
I do not agree here.
Can we agree to disagree?
I maintain that TLS is not strictly required for email protocols (SMTP,
POP3, IMAP) to function. All three did their job admirably for decades
without TLS. They are still as capable today as they were 20 years ago.
I completely agree that we want to NOT use unencrypted communications
for the reasons you cited as well as others.
I'll posit that a VPN between my notebook and my email server protects
the email protocols just as well, if not better, than TLS on each protocol.
So again, TLS is not strictly required for email to function.
Don't forget that both are used by clients (Submission),
Yes.
the plaintext for that is deprecated for years,
Agreed.
But deprecation is not the same as non-functional.
Link - Deprecated Definition & Meaning - Merriam-Webster
- https://www.merriam-webster.com/dictionary/deprecated
The four meanings that Meriam-Webster provides for deprecation all imply
that something is depreferenced, desire to avoid, should not use.
However none of them mean that it is non-functional.
recently even STARTTLS was marked as legacy (sorry, i don't remember
RFC number).
Again, legacy is not the same as non-functional.
Link - Legacy Definition & Meaning - Merriam-Webster
- https://www.merriam-webster.com/dictionary/legacy
Both meanings of the adjective for legacy indicate that something is
older or otherwise not current. Again, none of them mean that it is
non-functional.
Running these over plain text is questionable even in
LAN,
Why would you have ever used something -- independent of the location of
it's use -- if it didn't function?
Questionable is not the same as non-functional.
Link - Questionable Definition & Meaning - Merriam-Webster
- https://www.merriam-webster.com/dictionary/questionable
All three of your terms; deprecated, legacy, and questionable have
significantly more to do with if they would be chosen to be used today
and effectively nothing to do with if they function or not.
especially with wireless connections.
Wireless is very much so about locality, as in the (in)security of the
network.
I'll maintain that SMTP, POP3, and IMAP without TLS will work perfectly
fine and quite securely in a VPN over an insecure wireless network.
The protocols themselves still function and do the job that they were
designed to do.
This makes TLS strict requirement for Submission, IMAP & POP3, in
best with trusted certs.
I disagree.
Submission, IMAP, and POP3 are quite capable of functioning without TLS.
That being said, I absolutely agree that SMTP's Submission, IMAP, and
POP3 SHOULD NOT (a la. RFC) be used without some form of encryption.
N.B. That encryption can come from TLS support in the protocol -or- it
can come from some other mechanism outside of the protocol; e.g. a VPN.
I'll still argue that TLS is not strictly required for SMTP, IMAP, and
POP3 to function.
In SMTP (MTA-MTA) it is not as strongly required, but IMO after
Snowden, using it without TLS must be only rare. Sure, one cannot
know how mail will be relayed latter, but one have maintain/setup own
services.
Sadly, I find that MTA-MTA use of STARTTLS is not nearly what I would
hope that it is.
Please, how this DKIM certificate looks as? Where its format is
defined?
I'd have to go look things up, but I don't think that the certificate
format is defined anywhere. Rather DKIM focuses on the permutations
(read: math) applied to selected part of the messages. Howe the keying
material is stored for that on a given server is implementation dependent.
The RFCs do go into how and where the public keys are (ostensibly stored
in) accessed via DNS.
:-)))
IMO because here are missing some steps:
+ define/clarify terminology (someting as DNS has RFC for)
SMTP, POP3, and IMAP all have many RFCs defining things the same way
that DNS does.
I'd even argue that DNS is more complicated than SMTP, POP3, and IMAP
combined. The RFCs for DNS are notoriously complicated and prolific.
Conversely, the RFCs for SMTP, POP3, and IMAP are more straight forward
and build on each other.
+ define/clarify MTA roles
In many ways the roles are outside of and independent of the protocol.
RFCs are defining the protocol.
While i conider the first as doable (IMO really missing), the second
will be hard, due email flexibility here are too many roles and try
to describe them will be outdated/incomplete right after publishing.
I'm not going to take the time to chase chains of RFCs for SMTP, POP3,
and IMAP now. But I know that RFC 822 is a well known entry point for
SMTP and the two or three primary refreshes thereof.
It looks like RFC 1939 is related to POP3.
It looks like RFC 3501 is related to IMAP.
I know that all three protocols have many RFCs that extend, update, and
correct earlier RFCs in the chains.
I've always found RFC-Editor and IETF to be good sources for chasing
things down authoritatively.
Aside: Most RFCs will list any RFCs that they update / obsolete. So if
you start with current, you can almost always work backwards.
IMO here is only one way for that BCP -- do not try make it
universal, but publish it per MTA role, eg. BCP for outgoing (to
public net), BCP for for MX (from public), BCP for backup MX, etc,
etc.
I think that we are scoping Best Current Practices differently. There
are both things that are good to do; e.g. encryption, authentication,
and then there are documents that suggest various things. Said
documents can become outdated. Suggestions like encryption and
authentication tend to span specific documents.
N.B. that best current practice does not mean that the previous practice
is any less functional. It just means that any given BCP is currently
considered to be the best.
And really first step have to be to define four letter abbreviation
for Submission, because nobody will write Submission instead of SMTP.
While both use the same protocol, its requirements differs and using
SMTP word for both complicate it.
SMTP /is/ the protocol for Submission.
Submission is meant for user to server email submission process -- hence
it's name.
Submission tends to imply an alternate port.
I say imply because nothing dictates that port 587 nor 465 be used.
You can easily host submission services on TCP port 25 of your main /
only email server.
Is such advised? No. In fact, it's discouraged. But it will function.
Untill all forms (big, small, personal, etc) of email operators will
not be taken into account, it will not be usefull.
I agree that we can't (relatively) safely rely on it until a significant
majority are using it.
But even then, we can't guarantee that it will be used.
I still think that we can benefit from using things now before everybody
else is using it. -- Lest we get stuck in priming problems.
Yes, I practice what I'm preaching; I've got DNSSEC and I'm using dual
stack on my MTA. -- Strive for the anticipated future and hope that
others catch up.
Somebody has to start this parade. Sometimes it needs to be you.
Yes, mention only IPv4 decreases quality. And using IPv6 slighty
complicates things -- is one host the ::/128 or the ::/64 ?
/128 is one host.
/64 is 2^64 hosts.
There may be one host on a /64 network.
Because people tends to simplify things, using induction (which
mostly doesn't provide right result): compromised host are attacking,
simplest hosts to compromise are end users and IoTs, they have
dynamic IPs, thus all dynamic IPs are wrong.
That whole is wrong. It is wrong, because not all end user's hosts
nor all IoTs are compromited and because not only end user's hosts or
IoT are compromited. On rise of VPS, i am not sure if they have to be
considered as not end users's hosts, at least this cannot be
generalized, especially not generalized by IP, but they often has
static IP...
I'm taking that to be that you agree that the SMTP protocol functions
the same on a dynamic IP as it does a static IP.
Cloud is magic word, which will solve all your problems :-D
I hear people say that.
Mutch nice will be, to use hello based on target domain, but that is
near to impossible in environment sharing the same host (IP) for
multiple domains. Partially solvable after STARTTLS with SNI, but
that happens after initial hello...
The port is important here. }:-)
It's trivial to use different certificates on different IP+port pairs.
It's /currently/ quite difficult to get unaffiliated email servers to
send to any port other than 25. Some of the various ongoing efforts for
service location might change this.
I use debian's oldstable, even oldoldstable. Are they "completely
up-to-date"? AFAIK they are... No known security holes...
Do not forget, that any SW has bugs, thus software update comes with
new bugs ;-)
And we are back on terms clarify...
It is important to be using the same meaning for the same words.
We can't have a discussion if I say QUACK in place of email and you say
BONK in place of TLS without knowing what each other are doing.
"Conspiracy theory" -- is it term for things, for which someone is
happy, that facts about it are not public (yet)? What eg. GDPR is
trying to solve was named as "conspiracy theory" before it...
Fair.
I'll re-phrase more bluntly.
Didn't the U.S. Department of Justice have problems with Microsoft using
it's market dominance position to coerce people to use Microsoft's web
browser, Internet Explorer during the mid (?) '90s?
I draw this analogy to highlight using market dominance to coerce the
market to do something you want is disliked.
No SMTP was designed with outages in mind.
I completely agree.
I often preach this fact.
One have to try delivery repeat for at least 5 days.
Sadly, many systems don't retry at all and more systems still don't
retry for the RFC suggested five days.
That this not allways happen? Sure,
people are forgetting that things are not alwas smooth...
Sadly, many of the instances that I'm aware of are not forgetting nor by
accident. Rather they are done as part of a deliberate choice.
I was saying that you want someone / something, e.g. a backup MX, to be
available all the time to receive messages.
This can be a pair or trio of servers so that it's highly likely that at
least one of them is up and accessible to receive message on your behalf.
I'll argue that it's a best practice to get inbound email out of the
sending email ecosystem into the receiving email ecosystem as soon as
possible. I say this because you have virtually no control over the
sending email ecosystem, e.g. their retry interval / policy / etc.
Conversely you have considerably more influence over retry interval /
policy / etc. on systems in your inbound email ecosystem. Or at least
you should. If you don't, I suggest you question your inbound email
ecosystem.
What is OK for one target can be BAD for another.One cannot satisfy
all, we know.
Agreed.
"Good reputation" is bad wording into best practices.
I don't agree. I believe that reputation can be quantified in some ways
and I think that quantization can be compared to others. Ergo it's
possible to determine reputation and if it's good or bad.
In many ways "reputation" is a single word for what may be described as
"community consensus".
If more recipients think that a given sender is unpalatable than another
sender, then the former sender has a worse reputation than the latter
sender.
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
