On 7/12/23 4:11 AM, Slavko via mailop wrote:
BTW, my English is not best, don't take me word by word, please...
I don't think I've had any more trouble understanding you / your use of
English as an additional language than I have had with others who use
English as their primary language. Different uses of meanings of words
happens within languages too.
Perhaps that was goal, but if so, then i much more like the language
eg. of RFC5321: ...something "is out of scope of this document".
That works for me.
The only problem here is, that some sites/tools doesn't respects
that broken signarure have to be treated as no signature. But that is
not DKIM's mistake.
I consider / classify that as a problem with a given site's use or
configuration of DKIM not a problem with DKIM itself.
Individual DKIM installations and DKIM in general can cause problems.
But the former is much more localized to the specific installation while
the latter tends to be common across multiple installations.
What is not clear, at least from my point of view, is p=none policy.
RFC mention it as way to not enforce any policy, but receive
reports.
But what then if DMARC's p=none, no DKIM and SPF fails? Have to be
applied SPF result or have to be applied none policy?
In my opinion, if a domain's DMARC has a p=none, then you don't filter
on DMARC. But you still independently apply your site's local SPF
filtering policy preferably following the sending domain's stated SPF
wishes. The only thing that you would do with DMARC is send the
notification of the result.
It is not about which action have i to choose. I wonder what one
can/have to expect from other sides... Yes i know, their servers,
their rules, thus one can expect relative anything. But no one can
expect anything even on RFC compliant targets...
I think that we should safely expect sites to be largely RFC, or BCP,
compliant. I consider that to be the middle of the road and for people
to stay on their side of said road.
BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none.
1) I would expect you to apply SPF independently of DKIM and DMARC if
the sending domain publishes SPF records.
2) I would expect you to apply DKIM independently of SPF and DMARC if
the message has DKIM headers and the sending domain publishes DKIM
information.
3) I would expect you to apply DMARC using the aforementioned SPF and /
or DKIM results if the sending domain publishes DMARC information.
A DMARC policy of none simply elides that 3rd step to me.
Of course, i do my best effort to be as interoperable as i can/know.
I consider that as crucial in mixed environment, as Internet is.
Perhaps ISP was not right abbreviation, sorry for that. I meant email
provider, but i want to avoid ESP abbreviation as it is often used
with conjunction of mass mail here.
I think that ISP and ESP are both correct. ISP is probably the older
answer with ESP being the newer answer.
As with all things (Internet related) some are abused or used for things
we don't like and they can earn an unpleasant meaning. But I believe
that Email Service Provider is exactly that, a company that provides
email service. What that email service is used for it independent of
the fact that it is providing email service.
Yes, there are some very questionable / shady ESPs. But there are still
many good ESPs.
IMO we basically agree, that plain text connection over public net
have to be secured. I would consider setting VPN for mail only as too
mutch effort, especially for regular users.
I absolutely agree that using some form of encryption is strongly
recommended and that not using encryption is ill advised.
Sure, there are cases when encryption is not needed, eg. i don't
encrypt communication to 127.0.0.0/8 and ::1, nor over LXC internal
bridge. But my original point was about connections over public and
semi-public networks.
But then nowadays best practices have to mention it.
Yes, encryption of some form is very much so a SHOULD in RFC speak.
But IMO in case of foreign services here is another mean: one cannot
expect, that it will be provided.
That surprises me.
Perhaps other parts of the world have been using TLS, either implicit or
explicit via STARTTLS, for so long that they are now no longer offering
service without TLS.
My experience has been that unencrypted connections are still offered in
the areas where I'm interacting. Usually unencrypted will work close to
the service (as in connected to the ISP's network) but may not work
further away.
I still people using really old configurations without TLS and ISPs not
choosing TLS when helping customers set up new systems.
In some ways, TLS has been viewed as "oh, you're one of the people that
want to be really secure", let me get the documents.
The notable exceptions that I've seen are the email oligarchs, some of
whom tend to be charging full speed ahead and dragging the rest of us
with them even if they are dragging us across rubble and broken glass.
I understand legacy as something to avoid if possible and/or expect,
that it can be not provided by remote side.
I get the avoid part. I don't know that I'd go so far as to say "if
possible".
I would expect that if the legacy thing is not provided, it's not even
listed as an option.
Sure. By questionable i meant, that i often read about LAN as about
secure environment. Of course, it is more secure than public net. But
eg. in job i didn't consider our LAN as secure network, for warious
reasons.
I think the LAN is secure in such as physical locality and the ability
to connect to it, either physically via cable or wirelessly with proper
codes.
Similar to how I think things sitting on my dining room table in my
house to be more secure than the same things sitting on the table on my
front porch. The house walls (LAN connectivity) provide a barrier and
thus some security.
There is also the fact that I will likely not knowingly allow unsavory
people to enter my house while I can't keep them from walking onto my porch.
LAN is more about locality.
In some ways, it's on the nose in the name: /Local/ Area Network.
We are still talking about "best practices", right?
That's a very good and germane qustion.
My words was not meant as to be included in it, but about ponting to
what have to be take into account, when writing that practices.
I was responding as to what is strictly required to have email function.
The minimum viable product as in what can send and receive email.
I still maintain that encryption is not required to exchange email.
But I absolutely agree that encryption is a best practice and SHOULD be
included.
Sure, SMTP, IMAP and/or POP (and many other application layer
protocols) will work independly of that if its transport channel is
secured or not.
That is the point that I've been trying to make.
That is not the question. The question is who can see
communication content and where the clients will be connected to.
That's an entirely different question with entirely different answers
and discussions.
There's everything between someone can't easily read your communications
with a sniffer or something like Firesheep all the way to active Monkey
in the Middle impersonating things using ... questionable certificates.
AFAIK, the TLS was designed to work independently on upper layer
protocols.
I think we are in agreement.
My understanding is that SSL, TLS's predicessor, was originally meant to
provide an encrypted transport that the application layer protocol would
go on top of unmodified.
Then some time later STARTTLS and the ability to switch from unencrypted
to encrypted came along.
Can you please elaborate more about this?
I've seen a LOT more MTA-to-MTA communications not utilizing STARTTLS
than I am comfortable with. MTA-to-MTA communications that I would
expect to use STARTTLS.
I don't have any data on hand to back up my observations.
My pont was, that DKIM uses keys pair. The certificate, as known eg.
in TLS, is basically public key + couple additional data... AFAIK
these additional data are not used in DKIM, just keys.
I think we are in agreement.
DNS was just example, of protocol where clarification of some terms
was done. Take as example this
https://en.wikipedia.org/wiki/Reverse_path -- how many terms are
used for one thing? Yes, i am aware about them (now), but when
someone starts with email server, he will be confused.
Agreed.
That confusion is one of the reasons why I try to always use my real
email address so that people can contact me and ask questions if they
want to. -- I believe in helping people learn so that they understand
the subject and thus can make their own informed decisions.
And we do not need to go on internet, take "forward" term in another
today thread here...
:-)
Yes, all MTA roles (except gateway) uses the same protocol. But we
are talking about servers, not about protocol itself. And, as you
already pointed, there are differences eg. on inbound and outbound
servers. And then we have servers who are doing both in one, and then
... and then ...
RFCs are best place to find how exact details have to work, but IMO
are not best place to start with some thing. They are mostly not
writen as guides, they often do not explain things into details,
which starter needs.
Agreed. RFCs, like manual pages, are great references. But they are
not known as a soft landing / jumping off point to learn something new.
Perhaps i wrote some not proper English words, but IMO we are both
are talking about the same thing.
:-)
If you see this as main difference, then you miss a lot of details.
Submission changes multiple SMTP requirements, eg. timeouts,
allows/requires message modification or requires eg.
autentification...
I both agree and disagree. There are some differences. But there are a
lot more similarities.
Submission often extends the timers. But nothing prevents the primary
MTA-to-MTA from also using those same timers. Save for the possible
addition of authentication, they still use the same verbs. If anything
they are more like different dialects of the same language.
I have even seen where MTA-to-MTA does use authentication.
Despite that Submission uses the same SMTP commands in background, it
is not SMTP.
I disagree.
Remember how submission came about. Submission used to be on the SMTP
port. The biggest differences being the addition of authentication and
encryption (to protect said authentication). Then at some point the
submission role was moved to another port, ostensibly 587 per RFC or 465
w/ TLS per others.
But SMTP and submission roles did share the same IP + port pair and even
the same daemon for a long time. They can still share the same IP +
port pair today if you want them to.
And there can be host with many (and many) IPv6 addresses on one
interface. AFAIK default limit on Linux is 16 addresses, but it can
be raised. And with temporary IPv6 addresses one host can have new
interface address every couple of secs (and when disables DAD even
more often) without effort... And on remote side one have minimal
chances to see, if that are different hosts or still the same...
I see little difference between IPv4 and IPv6 in regards to your statement.
That was point of my question. IPv6 is not just IPv4 with larger IP
space. Differences are not big, bur are here, exactly as in SMTP and
Submission.
Save for the mechanics / minutia of how each work, I see IPv4/IPv6 and
SMTP/Submission as functionally end-to-end effectively the same.
I can't currently think of anything that I can do with one that I can't
also do with the other, both IPv4/IPv6 and SMTP/Submission.
Yes, how it is configured and the commands that are run are somewhat
different. But I can still establish host-to-host communications and
exchange email on both protocols / services.
Please elaborate on what can be done on Submission that can't be done on
SMTP or vice versa.
N.B. my MTA of choice, Sendmail, is EXTREMELY flexible and will quite
happily allow me to do whatever I want wherever I want it if I configure
it properly.
N.B. I can easily co-habitate SMTP and submission together on the same
port without any special configuration.
Yes. Exactly as they will work, despite that if IP is located in BR
or in IN...
:-)
I know near nothing about any US Department ;-)
I think you're lucky.
https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.
Don't worry, spammers are repeating behalf them, thus in average all
is as expected ;-)
Most of the spam that I see doesn't repeat itself as in queue and re-try
delivery. Instead it seems to be a completely separate initiation
unrelated to the first.
Or, if it is a spam message that is queued and re-tried, it's likely a
message that is passing through an RFC compliant SMTP server that is
doing the queueing.
That has the same result as forgetting, they are just ignoring well
known fact...
In my opinion, actively ignoring is far worse than not remembering.
As in any other places, there are emails, which must be delivered
quickly, and those which can wait, and finally those, which nobody
will miss.
IMO Importance of backup MX depends on ratio between these types.
And on ignorance (see above) of other sides. Sure, for many companies
it will takes less money, if they will force others to maintain
backup MX, that to maintain own queue...
It is worth to consider. But on other side, that is only about last
hop (last to reach your system from ouside). Do you really cannot
sleep just because there can be many hops before, on which that
message is out of your control?
It has more to do with if / when there is a problem with the primary
server, the problem can often be resolved and queue processing initiated
on backup servers.
I've run into many systems that would (re)try delivery every 4 / 12 / 24
hours. So a 5 minute outage of the primary server could induce a 4 / 12
/ 24 hour delay. Conversely if the message made it into a backup MX, I
could usually have the message in the mailbox within 15 minutes.
Chances are good that many will not notice that the email delayed.
This is also an extension of "I can't fix what I don't control." mentality.
I am not sure now, but i meet word "goodwill" in our financial
system. I will guess, that it is something similar, or even the
same.
Yes goodwill is important. But anyway, i didn't find in any business
guide mention it- I will guess that it is considered as something as
obvious, that it not worth to mention...
Sadly, the bad parts of capitalism seem to be taking quite strong hold
here in the U.S.A. as in if it doesn't financially benefit someone, they
may very well not do it. Good will hasn't been used to describe many
businesses in far too long.
Yes, one can can quantify relative anything. Eg. 1 € is exact amount,
it is exact quantification. But that 1 € has different value for
different people... Does that mena that quantifying money is
pointless? No. That quantification only seems as objective, but it is
subjective...
In our language my use "to jump under train" (raw translation,
original -- "skočiť pod vlak"). Do you will jump under train, when
most of community will think that you have to do it?
I personally do my own thing. I'll ask people why they are jumping
under the train. Many will not answer as they are too busy jumping
under the train.
But, many people don't have any control over their email system. Most
people use the email oligarchs and they assume that the oligarchs won't
listen to their pleas, thus they don't even complain to the oligarch,
and instead just complain about it to people around them.
Communities are hard. There are communities of experts, and there
are communities of random people. But there are also communities of
stupids and communities of "bad boys" too. Etc, etc. Which one
community do you mean?
Yes.
Community can also be locally defined and purposefully nebulous based on
the speaker's choice at the time of speaking.
If the suggestions in best practices have to be useful, they must
stay on technical level and avoid vague terms, except of some
suggestions in separate section...
If the best practice is a technical one, I agree.
There are some statements that are best practice in various communities
that are quite unpalatable by other communities. Rome and the colosseum
and various forms of so called entertainment come to mind.
regards
Likewise.
Thank you and have a good day,
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
