Dňa 11. júla 2023 18:23:45 UTC používateľ Grant Taylor via mailop <[email protected]> napísal:
BTW, my English is not best, don't take me word by word, please... >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. Yes. >I suspect that some of that was on purpose as to not dictate what >recipients should do. After all, your server, your rules. 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". >I think SPF itself is relatively straightforward. Yes, it is. >IMHO DKIM is slightly more complex: More complex to implement, but othervise straightforward. 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. >DMARC is more complicated yet in what it checks. Its check & implementation is straightforward too. 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? 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... BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none. > Of course this is predicated on you wanting to utilize said > specification in an interoperable way. 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. >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. 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. >Can we agree to disagree? 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. >So again, TLS is not strictly required for email to function. 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. >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. But IMO in case of foreign services here is another mean: one cannot expect, that it will be provided. >Again, legacy is not the same as non-functional. I understand legacy as something to avoid if possible and/or expect, that it can be not provided by remote side. >Questionable is not the same as non-functional. 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. >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. We are still talking about "best practices", right? 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. >The protocols themselves still function and do the job that they were >designed to do. 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 not the question. The question is who can see communication content and where the clients will be connected to. AFAIK, the TLS was designed to work independently on upper layer protocols. >Sadly, I find that MTA-MTA use of STARTTLS is not nearly what I would >hope that it is. Can you please elaborate more about this? >> 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. 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. >SMTP, POP3, and IMAP all have many RFCs defining things the same way >that DNS does. 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. And we do not need to go on internet, take "forward" term in another today thread here... >> + define/clarify MTA roles > >In many ways the roles are outside of and independent of the protocol. 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 ... >Aside: Most RFCs will list any RFCs that they update / obsolete. So >if you start with current, you can almost always work backwards. 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. >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. Perhaps i wrote some not proper English words, but IMO we are both are talking about the same thing. >Submission tends to imply an alternate port. 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... Despite that Submission uses the same SMTP commands in background, it is not SMTP. >> 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. 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... 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. >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. Yes. Exactly as they will work, despite that if IP is located in BR or in IN... >Didn't the U.S. Department of Justice have problems with I know near nothing about any US Department ;-) >Sadly, many systems don't retry at all and more systems still don't >retry for the RFC suggested five days. Don't worry, spammers are repeating behalf them, thus in average all is as expected ;-) >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. That has the same result as forgetting, they are just ignoring well known fact... >I was saying that you want someone / something, e.g. a backup MX, to >be available all the time to receive messages. 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... >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. 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? >In many ways "reputation" is a single word for what may be described >as "community consensus". 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... 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... >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. 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? 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? 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... regards -- Slavko https://www.slavino.sk
pgpaDYAL_sWwW.pgp
Description: Digitálny podpis OpenPGP
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
