On 7/13/23 10:56 AM, Slavko via mailop wrote:
Ahoj,
Hi,
OK, our opinions are near the same, but still opinions only, without
something in RFC.
:-)
IMO one cannot apply SPF independently nowadays.
I absolutely think that it's quite possible to apply SPF independently
nowadays.
Sure, your recipients might not like you honoring the sending domain's
request. But who's problem is it really? Who is the most capable of
fixing the root cause of the problem?
Should we hold sending domains accountable for what they publish in DNS?
Or should we coddle them ostensibly because we know better?
"Honesty and ass-kicking" from Taylor Mali's What Teachers Make poem
comes to mind. "If you ask for it, then I have to let you have it."
Link - What Teachers Make
- https://taylormali.com/poems/what-teachers-make/
- https://www.youtube.com/watch?v=RxsOVK4syxU
Is it better to fail soft and slow or hard and fast?
As discussed multiple times, SPF breaks forwarding
Didn't the purported sending domain ask that messages not from
authorized sources be treated harshly? (Assuming SPF ends in "-all".)
Honesty and ... "-all" means that I am asking you to really reject email
not from sources that I authorize.
(thus can lead to false positives)
I question the veracity of a false positive if it's contrary to the
published SPF.
Sure, SPF publishers make mistakes. But what's better, to coddle them
and have transient delivery errors for a long time (fail slow and soft)
or make the errors very apparent to them (fail fast and hard) so that
they can fix them?
and its (soft)fail result can be overridden latter by DMARC,
What does does the requested handling; anything between "-all" and
"+all", have to do with overriding the result? Or is it that you're
only willing to override specific requests, possibly from specific people?
and one don't know DMARC result before evaluate it...
So?
I'll argue that if I set a "-all" on my SPF record that I really
honestly and truly want no server than my authorized server to send
email claiming to be from me. This includes mailing lists.
IMO applying DKIM independently is pointless from start.
Okay. The value of a result of a test is somewhat orthogonal to if the
when the test can be run.
As this, DKIM is good only for statistical purpose, eg. to count
reputation for success DKIM's domain.
DMARC finally checks them both + alignment, but can be evaluated only
after full message body was received. As it can negate (soft)failed
SPF, it must be evaluated, to know if and which policy sender
defines.
Only after DMARC is evaluated and found no DMARC policy (record) or
p=none, pure SPF can be applied.
That is one way to apply SPF. But it doesn't mean that SPF can't be
applied differently.
But one still needs to do DMARC record discovery, and as it is based
on MIME From: domain, cannot be discovered before full body is
received. That negates one big SPF advantage -- apply before body was
received...
Success DMARC with p=none has the same wight as with any other
policy. IMO the difference is/have to be only on failed DMARC.
No, that was not what i talk about. Plain text SMTP is not
deprecated nor legacy, it is part of SMTP definition. It have to be
not suggested (or avoid) only novadays for reasons outside of SMTP.
Perhaps i am too affected by my previous job (army's IT, encryption,
etc), or i am simple paranoid. But as Snowden show us many years
ago, not only bad boys are spying. And as social networks shows,
collection of many small details (which are all not important by
self) can reveal important complex information about individuals...
I absolutely agree that encryption SHOULD be used.
I also absolutely agree that email can function without encryption.
Yes, a meet that too, i avoid that services if possible (i know,
that you don't like my "if possible").
Avoiding services with an unfavorable configuration doesn't mean that
the services don't exist.
No. I consider encrypting/protecting network connection as normal
behavior. Exactly as anyone distinguish own behavior on public
places and at home...
I agree that encryption should be the norm. I think it is becoming the
norm. But I don't think we are there yet.
I my job, i have boss. He is independent manager, but still has own
boss (raw terms). From time to time the boss's boss does some
resolution or directive, eg. my boss must use their email system. And
that email system provides only legacy 587/tcp connection. It is not
possible for me to avoid it, as that provider MUST be used...
I get it.
In any other situation, i will either ask to provide better service
(pointless in this case) or change provider (impossible in this
case). That is point of "is possible"...
ACK
Or, i have one appliance with relative old SSH server is running,
which doesn't understand nowadays OpenSSH signatures. I had to allow
legacy sinature in my client, but only for that appliance, not
globally. Thus i avoid old signatures, where it is possible...
Yep. I have the very same thing. I have the requisite parameters
specific to those hosts in the OpenSSH client configuration file.
Sure, when it is not provided, then it is not provided and one
rarely can expect, that someone will enable it...
AFAIK, technically it is about used technologies/protocols. Nobody
will be success to connect with twisted pair cable from EU to USA.
Nor via WiFi...
I don't think it's about protocols. We can send 802.2 really, Really,
REALLY long distances over fiber / RF (as in outer space) these days.
We get into the minutia of what is a given technology.
Yes, but that minimum is important here. Do you really think that
minimal working MTA is enough today? Especially for public net...
For some situations, yes. For a someone trying to learn things, yes.
For a lab environment, yes. For a business selling email services, no.
Why is a hobbyist running an MTA on a low power computer at home any
less of an email server than an ISPs running the same MTA software on
servers 25 years ago? Especially if said hobbyist is able to
successfully exchange email, possibly with the email oligarchs.
But our discussion start about email server, not about SMTP
protocol, despite that SMTP is main part of email (MTA) server.
But if an email server (SMTP, IMAP and/or POP ... work independently of
if it is transport channel is secure or not -- your words) works without
encryption, then it's still an email server with or without encryption.
So why does the lack of encryption make the system not an email server
compared to if encryption was added?
I say this because I think that people don't /need/ to learn about /
mess with encryption when they are /first/ starting to learn about email
servers.
Much like student drivers focus on the mechanics of driving and later
add more features like creature comforts /after/ they show that they can
keep the car between the lines.
Should encryption be done? Absolutely.
Does not doing encryption mean that it's not an email server? Not at all.
IMO i got your concern. I do not suggest to disable plain text SMTP
at all, it is good last resort fallback if TLS things go wrong. But i
still consider TLS (and all related things) as crucial for modern
server. I leave decision, if mail can be send over plain text to
sender.
I agree that any commercial email service provider should, maybe even
must, provide encryption. But a commercial ESP is a very specific
market segment. It's also the segment of the market that's about as far
away from the entry into the email ecosystem as you can get. ESPs face
significantly more and more complex problems than a small email server
used to get one's feet wet in the email ecosystem.
Of course, TLS is not holly grail of privacy, nor magic word...
;-)
TLS is a very good tool to have in the tool box and seems to apply quite
well to many situations. I think it behooves anyone serious about doing
anything more than hobbyist / learning to spend time learning about and
implementing TLS.
But that's beyond the minimum viable product.
While i am not getting too much messages, i see connection without
STARTTLS mostly only from aliexpress.
Encryption is hard. I will leave its technical hard aside. It si
hard in that mean, that one either need to use it all time, or
carefully evaluate **every** situation to be success. Regular people
are not willing to spend time to evaluate every one communication and
often fail to properly decide what have to be encrypted and what not
need that. And even if they will do that properly, people do
mistakes. Sometime nobody notice that mistake, and sometime results
can be catastrophic ...
Agreed.
Yet another reason why I think that basic email servers don't /need/
encryption.
Should it be there, yes, eventually. But not from the start.
I am not sure now, do you mean by "extends the timers" that allows
longer timeout? AFAIK exactly vice versa, MSA allows shorter
timeouts, see RFC 6409 sect. 5.3.
I've routinely seen MSAs configured with longer time out values than
MTAs. This harks back to when people were on modems sending emails with
attachments and it took wall clock time for the attachment to send.
Wall clock time that had to be accommodated from the MAIL FROM to the
<CR><LF>.<CR><LF> at the end of the DATA.
I've seen MSAs allow for up to 15 minutes for this on systems that had
MTAs cut sending servers off at 60 seconds.
The difference is that MTA can provide it, but on MSA it is
mandatory.
I've seen MSAs that don't use authentication. Or rather use the IP
address as the determining factor of if you're allowed to use the MSA or
not.
I am sure, that you know, that well known ports (IANA registered) is
only convention. The exception is MTA-MTA communication, but just
because here is no way to signal another port to remote side...
Yep.
Can be done? Relative anything what you want and what your SW allows
you. The difference is on what is or is not allowed/required to
do...
The "allowed / required" stems from RFCs with MAY (NOT) -> SHOULD (NOT)
-> MUST (NOT). But as -- I assume -- we are all aware RFCs are an
interoperability guideline. It behooves us to follow them. But as
another thread discusses (Y/AOL SOA requirement), servers go off book in
really weird ways that work perfectly fine with most implementations.
I have collected/extracted all differences from RFC, but i
translated that, and trying to translate them back to English will
not provide expected result, thus only shortly, MSA/Submission:
+ shorten timeouts
+ modifying message encoding
+ change body/MIME addresses
+ requires auth
+ and more
The only ones that I've not spoken about violating that list is the
modifying message encoding / MIME type. So, I've seen both MSAs and
MTAs receive 8-bit email and need to change it to 7-bit email, thus
necessitating modifying the encoding / MIME type. Thus my opinion is
that your list of differences seems is effectively a No Op to me. Ergo
MTA and MSA are to a very large degree the same with minor tuning that
can stand in for each other.
I would wager that it someone were to do something nasty with NAT in the
network, most people would not notice the difference between MSA and MTA
or vice versa in many cases.
I'm sure there are MTAs that don't offer authentication thus MSA clients
configured to use it would know.
Or that the differences between the MSA and the MTA is down to tune able
values and that each could be tuned to accept the other's traffic blindly.
While that can be done on MTA too, in many cases that will be direct
violation of SMTP. And you stated above, that we can expect RFC
compliant services, that is IMO why they was separated.
What's the actual violation? What fails to function from and end users
stand point?
It's quite possible to be interoperable without being RFC compliant.
There are all sorts of email servers that are not RFC compliant. Do you
read your postmaster@ / abuse@ email addresses? }:-) I do.
Thus, secret lies in details, not in basic functionality.
If the details are in the minutia, is there really an effective difference?
I don't know about where you are, but where I'm at, we are seeing
restaurants add / repurpose 2nd entrances for to go / pickup orders to
change traffic flow through their lobby. But that doesn't mean that the
other entrance can't be used.
I think this is a very good comparison between MSA and MTA.
Of course that both provides the same functionality, as they are
both L3 protocols. On modern Linux even most commands can work with
both, eventually selecting by -4/-6 options...
Thus again, the difference lies in details. Eg. you stated that /64
is 2^64 hosts, but that is 2^64 addresses, nobody can know (perhaps
except network admin) how many hosts these addresses represents.
Another difference (not related to email) is that ICMPv6 becomes
crucial part of IPv6 (at least its NDP part). Working without NAT can
provide another surprise for those, who are not aware of difference.
Etc, etc...
There are absolutely technical differences between administering IPv4
and IPv6. But what is / can be done across them, I'm not aware of a
difference.
I use exim, but it is highly configurable and can do both in one
instance too, but i use separate instances for public MSA and MTA,
that greatly simplifies configuration.
For Sendmail, it's actually more complicated to run multiple instances
of the daemon. It's much easier to run one daemon with multiple
listening ports, possibly with different configurations thereon.
N.B. Most of the complexity is the fact that OS init scripts utterly
fail at the idea of multiple instances of the same daemon. Sendmail
itself is perfectly fine with multiple separate daemons on the same
system. They can even share some directories while others are dedicated
to each daemon.
That is what is see in majority of SPAM (or any other type of
unwanted emails) here.
Some time ago i checked how useful is my grelisting. I do
conditional greylisting -- in mean, greylisted are only messages
which cross certain score from rspamd. It affects less that 1 % of
messages but almost all was retried.
I used to use greylisting. I've evolved into using nolisting. The
sending MTA can immediately deliver to the next MTA in the list if it
want's to. No more delay than the time it takes the sending MTA to
initiate a new connection.
I agree.
:-)
I cannot comment anything in USA. I am happy, that i not need to
place money to first place...
Modern slaves? ;-)
Probably closer than either of us are comfortable with.
regards
Likewise.
Thank you and have a good day,
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
