IMAP functions got removed on PHP 8.4

[williamdes]

The IMAP functions got removed on PHP 8.4, they are not anymore in the default bundle.

See: https://www.php.net/manual/en/intro.imap.php

See: https://github.com/search?q=repo%3Aliuch%2Fdmarc-srg%20imap_&type=code

Debian is now running PHP 8.4 as the default version. But Debian has a package for it: php8.4-imap

The composer.json file should probably indicate that it depends on php-imap or recommends it.
Depending on if this is a backwards compatibility break.

The code for "check availability" should check for the imap function or extension and display a nicer message than

[liuch]

The IMAP functions got removed on PHP 8.4, they are not anymore in the default bundle.

Debian always has imap functions in a separated package. It is named php-imap (a dependency package). This dependency is explicitly mentioned in README.md. Wouldn't updating this file be enough?

The composer.json file should probably indicate that it depends on php-imap or recommends it.

I guess you're right. The composer.json file should be updated according to the README file.

The code for "check availability" should check for the imap function or extension and display a nicer message than

You mean the web interface? But then according to your logic I need to do the same checks for the other dependencies mentioned in README file. Wouldn't that be excessive? Perhaps instead I should implement configuration and dependency checking not only in utils/check_config.php, but also in the web interface... What do you think?

[williamdes]

Debian always has imap functions in a separated package. It is named php-imap (a dependency package). This dependency is explicitly mentioned in README.md. Wouldn't updating this file be enough?

For Debian I did the work and added it into the suggests section.

You mean the web interface? But then according to your logic I need to do the same checks for the other dependencies mentioned in README file. Wouldn't that be excessive? Perhaps instead I should implement configuration and dependency checking not only in utils/check_config.php, but also in the web interface... What do you think?

I did mean in the back-end, the web interface can receive the nice message. It already works great for this.

New error discovered:

dmarc-srg [error]: ErrorException: Function xml_set_object() is deprecated since 8.4, provide a proper method callable to xml_set_*_handler() functions in /usr/share/dmarc-srg/classes/Report/ReportData.php:67
Stack trace:
#0 /usr/share/dmarc-srg/classes/Report/ReportData.php(67): {closure:/usr/share/dmarc-srg/init.php:59}()
#1 /usr/share/dmarc-srg/classes/Report/Report.php(52): Liuch\DmarcSrg\Report\ReportData::fromXmlFile()
#2 /usr/share/dmarc-srg/classes/Report/ReportFetcher.php(123): Liuch\DmarcSrg\Report\Report::fromXmlFile()
#3 /usr/share/dmarc-srg/utils/fetch_reports.php(177): Liuch\DmarcSrg\Report\ReportFetcher->fetch()
#4 {main}
Error: Function xml_set_object() is deprecated since 8.4, provide a proper method callable to xml_set_*_handler() functions (-1)

Here is how to patch it: https://sources.debian.org/src/phpldapadmin/1.2.6.7-2/debian/patches/0005-Stop-using-xml_set_object-for-PHP-8.4.patch/
Or tecnickcom/TCPDF#734

I did the change locally, removed the "this" line
And changed the two lines to

        xml_set_element_handler($parser, [$rdata, 'xmlStartTag'], [$rdata, 'xmlEndTag']);
        xml_set_character_data_handler($parser, [$rdata, 'xmlTagData']);

Pushed as https://salsa.debian.org/php-team/pear/dmarc-srg/-/commit/fe5b7e0c24360bc1b80b2a12e98360b95a829163

[liuch]

The code for "check availability" should check for the imap function or extension and display a nicer message than

It have been fixed with 7041870.

For Admin user it looks like this:

[liuch]

dmarc-srg [error]: ErrorException: Function xml_set_object() is deprecated since 8.4, provide a proper method callable to xml_set_*_handler() functions in /usr/share/dmarc-srg/classes/Report/ReportData.php:67
Stack trace:

Fixed.

[williamdes]

Very cool!
Maybe change a bit the code to either no mix extensions and libs
or uses the standard syntax php-<ext-name> in the string

[liuch]

At first I wanted to display the package name there, but I wasn't sure if all Linux distributions named packages the same, so I decided to name the extension as it is named in the PHP documentation.

Maybe I didn't understand what you were suggesting. Could you give me some examples of this message?

[williamdes]

At first I wanted to display the package name there, but I wasn't sure if all Linux distributions named packages the same, so I decided to name the extension as it is named in the PHP documentation.

Maybe I didn't understand what you were suggesting. Could you give me some examples of this message?

Hmm, sorry for that confusion. After a second check I was thinking about how composer handles the extensions.
Maybe this is easier to align with ?

dmarc-srg/composer.json

Lines 16 to 20 in 89446b4

	"ext-json": "*",
	"ext-mbstring": "*",
	"ext-pdo_mysql": "*",
	"ext-xml": "*",
	"ext-zip": "*",

I wasn't sure if all Linux distributions named packages the same

Same, I am unsure there is a standard.

[williamdes]

Hi @liuch
Just for you to know if you install a Debian Trixie DmarcSRG will not be usable in terms of fetching emails because the php-IMAP extension no longer exists in Debian (https://tracker.debian.org/pkg/php-defaults) .
This is currently the state I am in on my server.
How easy would it be to allow another library to fetch reports?
this one is a modern and good one https://github.com/DirectoryTree/ImapEngine

[liuch]

Thanks for the information. I will update my project soon.

[liuch]

I plan to support multiple IMAP library options. Could you point me to some libraries that I should pay attention to? I am going to make a generic interface for easy embedding them.

this one is a modern and good one https://github.com/DirectoryTree/ImapEngine

Unfortunately, this engine does not support OAuth. I would like to close the problems with office365.

[williamdes]

Maybe this one for example https://github.com/Webklex/php-imap

@stevebauman do you have other ones in mind?

I found this not very updated one https://github.com/barbushin/php-imap

This one maybe has Outlook support https://github.com/javanile/php-imap2

[stevebauman]

@liuch Author of ImapEngine here. It definitely supports OAuth. I have several Outlook mailboxes connected via access tokens.

Or are you referring to Microsoft's Graph API?