Re: Mail delivery failed: 550 relay not permitted

[Eli Zaretskii]

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 <Mailer-Daemon@gnu.org>
> 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:
> 
>   emacs-devel@gnu.org
>     host lists.gnu.org [2001:470:142::17]
>     SMTP error from remote mail server after RCPT TO:<emacs-devel@gnu.org>:
>     550 relay not permitted
> 
> Reporting-MTA: dns; eggs.gnu.org
> 
> Action: failed
> Final-Recipient: rfc822;emacs-devel@gnu.org
> 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 <eliz@gnu.org>
> To: Andrea Corallo <akrl@sdf.org>
> Cc: phillip.lord@russet.org.uk, emacs-devel@gnu.org
> Subject: Re: [feature/native-comp] breakage on build
> 
> > From: Andrea Corallo <akrl@sdf.org>
> > Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> > 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?