The README recommends catching Alphagov\Notifications\Exception\NotifyException after trying the sendEmail() method, and then using $e->getCode() and $e->getErrors() to extract the exception info.

However the ->getErrors() method only exists on the ApiException class, so can't be relied on to exist when catching the parent NotifyException, which only has standard RuntimeException methods.

Hello,

I wondered if someone could help me with an issue whilst trying to install the PHP client?

I seem to be going around in circles when I'm trying to install the client using composer.

If I run this command composer require php-http/guzzle6-adapter alphagov/notifications-php-client
it says:

/guzzle6-adapter v2.0.1 requires php-http/httplug ^2.0

So I install php-http/httplug ^2.0 and run the command again and it says:

alphagov/notifications-php-client 1.6.2 requires php-http/httplug ^1.0 ->
satisfiable by php-http/httplug[v1.0.0, v1.0.0-RC1, v1.0.0-alpha, v1.0.0-alpha2,
v1.0.0-alpha3, v1.0.0-beta, v1.1.0] but these conflict with your requirements o
r minimum-stability.

How can I install the client? it appears that it is only compatible with httplug v1 but guzzle 6 is only compatible with httplug v2

Current composer dependency requirement for firebase/php-jwt is:

but I have a dependency in another library already being used in the same project to firebase/php-jwt: ^5.0 — would an upgrade to ^5.0 break functionality in this project?

Hi,

I have been upgrading from v1.6.2 to v4.0.1 and have hit an issue. I have installed via composer and want to use the curl implementation. I can't connect as per the documentation, as the types of the parameters used to instantiate the curl http client do not match. After some digging I have found that the guzzlehttp/psr7 version specified in the composer.json file is too low. The file is set as ^1.2 but you need a version greater than 2. Is this a known issue or is this done in this way for a reason?

Thanks in advance,
Dave

test

We have seen reports of mail sent via GOV.UK Notify being delivered into spam mailboxes. We can't know exactly what is causing this, but we have identified that the headers of the mail do not identify the mail as having an automated source.

(Some classification systems may treat automated mails, that do not declare themselves, as suspicious.)

It would help to address this if the email facility for GOV.UK Notify was extended to support two additional sender-specified headers.

1. List-Unsubscribe:

Senders should have the ability to specify a List-Unsubscribe header consisting of one or more comma-sepatated angle-bracket enclosed URLs.

For our purpose we would only need to specify one.

List-Unsubscribe: <https://example.blog.gov.uk/subscribe/[email protected]>

This URL would provide a mechanism for unsubscribe (but would be in addition to unsubscribe links in the body text).

This header would be used both by some email clients to provide easy subscription management, and by email filtering and classification systems.

Technical reference is:
https://tools.ietf.org/html/rfc2369

2. Auto-Submitted:

Senders should have the ability to specify an Auto-Submitted header with a valid value.

For our purposes "auto-generated".

Auto-Submitted: auto-generated

This header is used by mail processing systems, primarily as a means of avoiding mail-loops caused by auto responders.

Technical reference is:
https://www.iana.org/assignments/auto-submitted-keywords/auto-submitted-keywords.xhtml
https://tools.ietf.org/html/rfc3834#section-5
https://tools.ietf.org/html/rfc5230#page-8

We're trying to move to using the new 2.1 release of the client but have hit this issue. Our code uses PSR and injects a ClientInterface implementation into the NotifyClient constructor but this fails as it's expecting a HttpClientInterface (as linked above).

The thing is that HttpClientInterface is a direct wrapper, with no additional functionality over, ClientInterface. I'm loathed to bring in httpplug just so I can use this (but will if I have to)