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 https://github.com/tecnickcom/TCPDF/pull/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 7041870f8ee9dcaa201125d92ffd810907a5598a.

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 ? https://github.com/liuch/dmarc-srg/blob/89446b44e7c29a9b97e82a6e8ad4a92cdc247214/composer.json#L16-L20

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?

[liuch]

@stevebauman That is nice! Sorry for my bad.

[williamdes]

Thank you for adding ImapEngine support! Now I have to package it into Debian 😁😁