Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

AEM 6.2 Adaptive Forms not sending email

Avatar

Level 1

Hi,

The problem:

We are on AEM 6.2 and are trying to make use of the Adaptive Forms, but when submitting a form from the client-facing domain, it does not deliver the emails.

When submitting the form on the author server, it sends the email successfully.

Also, when submitting it directly on the publisher, it is also successful.

But when we are on the web server, which serves the content from the publisher, we get the successful message from the form, but the email never gets sent, nor can we see any errors that make sense.

The first thing to note is that we do not make use of the Dispatcher, but have other AWS infrastructure in place to give similar architectural behavior.

We have a WAF in front of our servers which originally gave an "Unable to read CSRF meta information" console error. After disabling the WAF, the error was now gone, but still no email.

The AEM error log only shows a bunch of the same error in quick succession:

*ERROR* [xxx.xxx.xxx.xxx [1531669370613] GET /contact.html HTTP/1.1] com.adobe.aemds.guide.taglibs.GuideELUtils There was certainly some problem in geti18n api

java.lang.NullPointerException: null

And this is the output of the errors in the console:

mime_type_error.png

Any assistance with making this work with our current setup will greatly be appreciated.

Thanks

1 Accepted Solution

Avatar

Correct answer by
Level 10

Couple of pointers as I'm not sure if the errors posted are related to "email" problem statement or something else -

1) check why the mime type of css is 'text/html',  it should be 'text/css; charset=UTF-8'. That could possibly break the HTML rendering. check the publish server(s) directly or otherwise figure out which server/proxy in your setup above publisher is modifying the content type. You should fix that.

2) If you have configured CSRF libraries in your code then check the CSRF related errors in logs or otherwise validate '/libs/granite/csrf/token.json' loads correctly on your page that has the form and CSRF is configured properly on the publish servers.

3) Validate the Sling Referrer Filter is configured properly in your publish servers and your request has appropriate host header that are allowed and not rejected by Sling Referrer Filter in /system/console/configMgr

4) Apply debug logs on specific code packages, mail packages (com.day.cq.mailer) and to get more clues. You may apply logs on CSRF and Sling filters to rule out any malformed request/headers since you have confirmed that the email service works directly in the publish servers

5) i18n error could possibly be ACL issue with service user on your code package or however you utilize i18n in your source code. It may help if you apply debug logs and find more pointers

View solution in original post

1 Reply

Avatar

Correct answer by
Level 10

Couple of pointers as I'm not sure if the errors posted are related to "email" problem statement or something else -

1) check why the mime type of css is 'text/html',  it should be 'text/css; charset=UTF-8'. That could possibly break the HTML rendering. check the publish server(s) directly or otherwise figure out which server/proxy in your setup above publisher is modifying the content type. You should fix that.

2) If you have configured CSRF libraries in your code then check the CSRF related errors in logs or otherwise validate '/libs/granite/csrf/token.json' loads correctly on your page that has the form and CSRF is configured properly on the publish servers.

3) Validate the Sling Referrer Filter is configured properly in your publish servers and your request has appropriate host header that are allowed and not rejected by Sling Referrer Filter in /system/console/configMgr

4) Apply debug logs on specific code packages, mail packages (com.day.cq.mailer) and to get more clues. You may apply logs on CSRF and Sling filters to rule out any malformed request/headers since you have confirmed that the email service works directly in the publish servers

5) i18n error could possibly be ACL issue with service user on your code package or however you utilize i18n in your source code. It may help if you apply debug logs and find more pointers