Since some weeks, the "reply to this email to respond" functionality returns a failure from a google mail server claiming the mails to be spam. Apparently, the mail server does not recognize that the mail has been a response to a post from the forum.
This is the latest mail server response:
From: Mail Delivery System <Mailer-Daemon@cloud3.handshake.de>
To: dieter@handshake.de
Subject: Mail delivery failed: returning message to sender
Date: Tue, 02 Jan 2024 08:54:19 +0100
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:
community+0e85e820f26781bdd0374178291fa78e@plone.org
SMTP error from remote mail server after end of data:
host aspmx.l.google.com [66.102.1.26]: 550-5.7.1 [88.198.35.2 12] Gmail has detected that this message is likely
550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this
550-5.7.1 message has been blocked. For more information, go to
550 5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError m13-20020a05600c4f4d00b0040d5af7969esi7014882wmq.105 - gsmtp
------ This is a copy of the message, including all the headers. ------
Return-path: <dieter@handshake.de>
Received: from smtpproxy (helo=localhost)
by cloud3.handshake.de with local-esmtp (Exim 4.84)
(envelope-from <dieter@handshake.de>)
id 1rKZbN-0006av-0h
for community+0e85e820f26781bdd0374178291fa78e@plone.org; Tue, 02 Jan 2024 08:54:17 +0100
Received: from localhost (127.0.0.1) by cloud3
Received: from ixdm.fritz.box (localhost [127.0.0.1])
by ixdm (8.15.2/8.15.2/Debian-18) with ESMTP id 4027sG82004459
for <community+0e85e820f26781bdd0374178291fa78e@plone.org>; Tue, 2 Jan 2024 08:54:16 +0100
Received: (from dieter@localhost)
by ixdm.fritz.box (8.15.2/8.15.2/Submit) id 4027sG49004456;
Tue, 2 Jan 2024 08:54:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <26003.49448.334445.594722@ixdm.fritz.box>
Date: Tue, 2 Jan 2024 08:54:16 +0100
From: "Dieter Maurer" <dieter@handshake.de>
To: Plone Community <community+0e85e820f26781bdd0374178291fa78e@plone.org>
Subject: Re: [Plone Community] [Zope] Help needed on content-length issue and Un authorization issue for redirection
In-Reply-To: <discourse/post/61219@community.plone.org>
References: <discourse/post/61219@community.plone.org>
X-Mailer: VM 8.0.12-devo-585 under 21.4 (patch 24) "Standard C" XEmacs Lucid (x86_64-linux-gnu)
Buvi via Plone Community wrote at 2024-1-2 06:23 +0000:
> ...
>Issues:
>
>1. When the user is login in for the first time, ideal scenario is to give the login page to enter the username and password.
>what i did is created a login page using the response.write method pushed the login page for the user
"response.write" is for special applications only.
Typically, you do not use it for a login page -- or anything you
can generate via a Page Template, DTMLMethod or DTMLDocument, Script(Python),
etc.
A "login" functionality is typically implemented via a template
representing the login form and some logic to implement the
associated login action, this logic verifies the correctness
(comparing the form provided data against a user source)
and sets up an authentication session (usually via setting a cookie).
If you follow this route, the framework handles the response headers
and body by its own -- no need for `response.write`.
Implementing the "login" functionality correctly is not trivial.
You may look at `Products.PluggableAuthService`, a `Zope` extension.
It allows to implement the various subtasks associated with
authentication via plugins.
It comes with plugins for a simple user source and
a login form and cookie based login functionality (--> `cookie_auth_helper`).
You will need something of your own to populate the user source,
e.g. implement a registration form.
> framework is understanding it has Unauthorised and framework is pushing the unauthorised body(Unauthorizsed message) and appends it to the response.body.
You have not told us how you tried to implement your "login page".
The use of `response.write` is not responsible for an "Unauthorized"
response (even though, you should not use `response.write` for this
purpose). Almost surely, the "Unauthorized" is raised when you
"login page" is accessed initially (due to bad security declarations).
You can analyze "Unauthorized" problems by configuring
`Zope` for "verbose security". This is far less efficient (you
do not want it in production),
but gives detailed information why "Unauthorized" has been raised.
Look at the comments in the Zope configuration file (typically
`etc/zope.conf`) to learn how to configure `Zope` for verbose
security.
>where response.setbody method is setting the content-length to response.body message not to the response.write value, due to which content-length is setting to lower value, than the expected value of response.write.
Usually, you do not call `response.setBody` either.
Typically, it is done automatically for you.
You are trying to use the `Zope` framework at a far too low level.
You should start with reading the `Zope` documentation
at "https://zope.readthedocs.io/en/latest/".
There are essentially two high level APIs:
1. the old one based on management via the Web (called the
"Zope Management Interface") documented in the "The Zope Book"
2. the new file system based API centered around components
(utilities, views, adapters, events) documented in the
"Zope Developer's Guide".
Both documents are linked from the main `Zope` documentation.
>2. When i use response.redirect to bring up the login page, there also i see the Unauthorised is been set to the response.body due to this unauthorised, response.status is been set 401 instead of 302(redirection status code).
As before, the "Unauthorized" is likely generated at the initial
access to whatever you have implemented (due to wrong security
declarations). If this is true, then your `response.redirect`
has not been executed at all.
If `response.redirect` is executed, it can "lock" the response code
(using the "lock" parameter with a true value).
But, as written above, you code likely is not executed at all.
What I find strange is that the message was sent to
community+0e85e820f26781bdd0374178291fa78e@plone.org and not an address at community@plone.org.