Please see the rejected message below. Why did lists.gnu.org say "relay not permitted"? I sent this message via the SMTP server on fencepost.gnu.org, so what relay is involved here?
How can I avoid this failure in the future? TIA. > Auto-Submitted: auto-replied > From: Mail Delivery System <[email protected]> > Date: Mon, 01 Feb 2021 12:01:32 -0500 > > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > [email protected] > host lists.gnu.org [2001:470:142::17] > SMTP error from remote mail server after RCPT TO:<[email protected]>: > 550 relay not permitted > > Reporting-MTA: dns; eggs.gnu.org > > Action: failed > Final-Recipient: rfc822;[email protected] > Status: 5.0.0 > Remote-MTA: dns; lists.gnu.org > Diagnostic-Code: smtp; 550 relay not permitted > > Date: Mon, 01 Feb 2021 19:00:46 +0200 > From: Eli Zaretskii <[email protected]> > To: Andrea Corallo <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: [feature/native-comp] breakage on build > > > From: Andrea Corallo <[email protected]> > > Cc: [email protected], [email protected] > > Date: Mon, 01 Feb 2021 16:20:17 +0000 > > > > > OK, thanks. I understand the reasons now. However, I'm not sure we > > > should encode all this information in the .eln file's name. For > > > starters, some of those reasons are also true for *.elc files, right? > > > For example, suppose that a primitive that the .el file calls changed > > > its signature in backward-incompatible ways -- the .el files which > > > call it need to be recompiled, or else they will fail, either silently > > > or noisily. Right? But we don't encode those details in the names of > > > the *.elc files, do we? Why should the *.eln files be different? > > > > I think with eln the situation is considerably more sentitive than the > > elc one in this respect. The reason is that we (on purpose) skip > > Ffuncall to call directly into C code, as a consequence an > > incompatibility will most certainly lead to a crash and not a runtime > > error. > > Crash aside, I don't see the crucial difference, sorry. And if we > detect incompatibility and prevent the crash, I seed no difference at > all, as that can happen with *.elc files as well. > > > 2- We move HASH1 into the eln as metadata. > > > > - The limitation of 1 persists > > > > - To check that each eln is loadable one has: to 'dlopen' it, read the > > metadata ('dlsym'), verify and in case reject. This is certainly > > way more expansive than directly searching for a given filename and > > might impact negatively startup time, especially on certain OSes > > where opening files is an expensive operation. > > How much more expensive? I'd be surprised to hear it's significant, > since in-memory operations are much faster than file I/O. Is it > possible to measure the difference, so that we could make a decision > based on facts? > > > - We'd have name clashes for different eln coming from different > > Emacs configurations/versions. > > A different version will have a different directory, like it does now > with *.elc files. As for different configurations: if you mean the > same architecture, how probable is that, for normal users? If the > issue happens with Emacs developers, wed could design something > special for that case. > > I guess I'm saying that using the file names to record this > information is not necessarily justified by the issues it is supposed > to solve, and there are alternative solutions with smaller costs. > > > Shall we pick a length? 8 characters is probably more than okay but we > > can go for 16 if we prefer to stay on the safe side. > > If 8 is enough, then why go for 16? How is that safer?
