Ahoj, Dňa Wed, 12 Jul 2023 10:04:10 -0500 Grant Taylor via mailop <mailop@mailop.org> napísal:
> 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. OK, our opinions are near the same, but still opinions only, without something in RFC. > 1) I would expect you to apply SPF independently of DKIM and DMARC > if the sending domain publishes SPF records. IMO one cannot apply SPF independently nowadays. As discussed multiple times, SPF breaks forwarding (thus can lead to false positives) and its (soft)fail result can be overridden latter by DMARC, and one don't know DMARC result before evaluate it... > 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. IMO applying DKIM independently is pointless from start. Failed DKIM have to be considered ad no DKIM at all. And success DKIM means relative nothing, as here is no way to find reliable relation between sender and d= domain, thus anyone can fill "own" d= domain. As this, DKIM is good only for statistical purpose, eg. to count reputation for success DKIM's domain. > 3) I would expect you to apply DMARC using the aforementioned SPF > and / or DKIM results if the sending domain publishes DMARC > information. 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. > A DMARC policy of none simply elides that 3rd step to me. 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. > 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. 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. > 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. 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 still people using really old configurations without TLS and ISPs > not choosing TLS when helping customers set up new systems. Yes, a meet that too, i avoid that services if possible (i know, that you don't like my "if possible"). > 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. No. I consider encrypting/protecting network connection as normal behavior. Exactly as anyone distinguish own behavior on public places and at home... > I get the avoid part. I don't know that I'd go so far as to say "if > possible". 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... 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"... 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... > I would expect that if the legacy thing is not provided, it's not > even listed as an option. Sure, when it is not provided, then it is not provided and one rarely can expect, that someone will enable it... > LAN is more about locality. 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... > The minimum viable product as in what can send and receive email. Yes, but that minimum is important here. Do you really think that minimal working MTA is enough today? Especially for public net... > > 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. But our discussion start about email server, not about SMTP protocol, despite that SMTP is main part of email (MTA) server. 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. Of course, TLS is not holly grail of privacy, nor magic word... > 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. 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 ... > Submission often extends the timers. 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 have even seen where MTA-to-MTA does use authentication. The difference is that MTA can provide it, but on MSA it is mandatory. > 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. 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... > Please elaborate on what can be done on Submission that can't be done > on SMTP or vice versa. 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... 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 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. Thus, secret lies in details, not in basic functionality. > 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. 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... > 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. 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. > 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 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. > In my opinion, actively ignoring is far worse than not remembering. I agree. > 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. I cannot comment anything in USA. I am happy, that i not need to place money to first place... > 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. Modern slaves? ;-) regards -- Slavko https://www.slavino.sk
pgpoMAlDCI0yr.pgp
Description: Digitálny podpis OpenPGP
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
