savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers-public] [address@hidden: Bounce action notification]


From: Eli Zaretskii
Subject: [Savannah-hackers-public] [address@hidden: Bounce action notification]
Date: Mon, 02 May 2022 17:24:18 +0300

Lately I see several bouncing messages that originated on Emacs
mailing lists; one example is below.

It seems like Google now requires some authentication it didn't
require before.  I'm worried that this causes many subscribers to have
their email delivery disabled, and it will take them time to figure
out this happened and why.

Can we on our end do something to avoid this problem?

Thanks.

--- Begin Message --- Subject: Bounce action notification Date: Mon, 02 May 2022 04:23:38 -0400
This is a Mailman mailing list bounce action notice:

    List:       Emacs-devel
    Member:     emacs-devel@adamspiers.org
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at mailman@gnu.org.
--- Begin Message --- Subject: Undelivered Mail Returned to Sender Date: Mon, 2 May 2022 09:09:56 +0100 (BST)
This is the mail system at host coral.adamspiers.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<adam.spiers@gmail.com> (expanded from <emacs-devel@adamspiers.org>): host
    gmail-smtp-in.l.google.com[64.233.184.26] said: 550-5.7.26 This message
    does not have authentication information or fails to 550-5.7.26 pass
    authentication checks. To best protect our users from spam, the 550-5.7.26
    message has been blocked. Please visit 550-5.7.26
    https://support.google.com/mail/answer/81126#authentication for more 550
    5.7.26 information. z2-20020a056000110200b0020ad937cc1csi10132838wrw.211 -
    gsmtp (in reply to end of DATA command)
Reporting-MTA: dns; coral.adamspiers.org
X-Postfix-Queue-ID: 0EDBA2E726
X-Postfix-Sender: rfc822; emacs-devel-bounces+emacs-devel=adamspiers.org@gnu.org
Arrival-Date: Mon,  2 May 2022 09:09:55 +0100 (BST)

Final-Recipient: rfc822; adam.spiers@gmail.com
Original-Recipient: rfc822;emacs-devel@adamspiers.org
Action: failed
Status: 5.7.26
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication
    information or fails to 550-5.7.26 pass authentication checks. To best
    protect our users from spam, the 550-5.7.26 message has been blocked.
    Please visit 550-5.7.26
    https://support.google.com/mail/answer/81126#authentication for more 550
    5.7.26 information. z2-20020a056000110200b0020ad937cc1csi10132838wrw.211 -
    gsmtp
--- Begin Message --- Subject: Re: master 1b71c995da: Avoid binding mouse-1 in xref when mouse-1 doesn't follow links Date: Mon, 02 May 2022 10:02:29 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Dmitry Gutov <dgutov@yandex.ru> writes:

> If our goal is consistency with Grep, I suppose we should pick the
> command that's more similar to its behavior as well?
>
> AFAICS mouse click in Grep selects the location's window in the
> end. That's the behavior of 'xref-goto-xref'.

It makes sense to be consistent here, so I've switched the xref mouse
action to xref-goto-xref, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no


--- End Message ---

--- End Message ---

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]