@apeksha-barhanpur

My apologies, I mistakenly believed you had a support plan with FusionAuth (let me know if I am mistaken).

Regarding your question --

Have you had a chance to review the troubleshooting guide that we publish for email?
https://fusionauth.io/docs/v1/tech/admin-guide/troubleshooting#troubleshooting-email

Lastly, a good tip is to remove FusionAuth completely from the email equation by using SWAKS. SWAKS will complete an email exchange with just your email provider credentials (thereby removing FusionAuth from the equation). If SWAKS fails, then would offer good troubleshooting information.
http://www.jetmore.org/john/code/swaks/

Thanks,
Josh

A couple of things:

https://fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email has troubleshooting tips worth checking out.

The UI copy doesn't copy the SMTP password, so double check that as well.

You want to look at https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-populate/ This can update the email/nameId before it is sent over to the special SP.

You will want to create a separate application and set the Response Populate Lambda to the lambda which does this transformation. This can be done via the UI as illustrated here: https://fusionauth.io/docs/v1/tech/samlv2/

Yes. That’s how it currently works.

We have on the roadmap a more flexible identity system but don't have a current timeline for implementation. Here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

Ensure you are not using a reply address from @fusionauth.io; if you are this will fail our DMARC policy.

You don’t necessarily want to remove this reply address, but it should not be using our email domain. Instead it should be an address that belongs to your organization, such as no-reply@example.com. (Or, even better: customersupport@example.com--I hate when I get an email I can't reply to, myself.)

Each email template also has the option to override that default value with a different value. So you may also want to audit each email template to ensure if it is using a different From address, it is also owned by your domain.

If you are using email verification, you can check this user state within your own app. (So, don't allow the attacker to access anything until their email address has been verified.)

In version 1.27.0 you can configure a gated login flow when the user is not verified (this is a 'reactor' feature requiring a paid license). This will enforce email verification before we even redirect to your app. You can then also configure FusionAuth to delete users after N number of days if the user has not verified their email address. This can assist with build up of accounts that are not actually in use.

The recommended course of action is to store the email in the user.data.email field, which is not required to be unique but is still used for activities like 'forgot password' emails. Leave the user.email field blank and use user.username.

That should work. Support for user.data.email was removed in 1.26 and added back in 1.27.2, so avoid version 1.26.* and 1.27.0 and 1.27.1.

I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3' services: mailcatcher: image: yappabe/mailcatcher ports: - "1025:1025" - "1080:1080" networks: - mailcatcher search: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 environment: cluster.name: fusionauth bootstrap.memory_lock: "true" discovery.type: single-node FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY} ES_JAVA_OPTS: ${ES_JAVA_OPTS} # Un-comment to access the search service directly # ports: # - 9200:9200 # - 9300:9300 networks: - search restart: unless-stopped ulimits: memlock: soft: -1 hard: -1 volumes: - es_data:/usr/share/elasticsearch/data fusionauth: depends_on: - search - mailcatcher environment: SEARCH_SERVERS: http://search:9200 SEARCH_TYPE: elasticsearch networks: - mailcatcher - search networks: search: driver: bridge mailcatcher: driver: bridge volumes: es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

A couple of options:

You could optionally configure a different template for each tenant so you could hard code the correct URL in each template.

You could also add the correct URL to the tenant.data and then pull it out in the template during render so you could use the same template across tenants.

If the state parameter is working well for you for other APIs, you could open a feature request in GH to add this to the API in question.

Does SendGrid indicate why they are rejecting requests? In my experience, this is generally due to invalid creds, or a “From address” with a domain that does not match your SendGrid account.

So if a default template is being used with a no-reply@fusionauth.io address you may see a runtime error such as a rejected SMTP request.

Otherwise I'd make sure the IP address is in any whitelists, or share anything else that sendgrid logs.

Since both APIs are technically the same, is there a way to use the email template defined for the Setup Password with the Forgot Password API?

Yes. Navigate to 'Tenants -> your tenant -> Email' and you can set 'Setup password' and 'Forgot password' to be the same template.

There may be template variable differences, please consult the documentation and ensure you are checking for existence before you rely on them:

https://fusionauth.io/docs/v1/tech/email-templates/email-templates/#setup-password

https://fusionauth.io/docs/v1/tech/email-templates/email-templates/#change-password

Each user is unique within a tenant by email address. If a user in the same tenant wants to login with Facebook, Google, or LinkedIn, it will be the same User object.

You are correct. The verified flag exists on the corresponding user and the registration. You could optionally use the "verify registration" templatefor this purpose.

If you then ignored the verified: false flag on the registration in your code, it should not impact you.

Another option would be to listen for the user.registration.create event and then fire off an email on your end, or call the Email Send API to send a pre-made FusionAuth email template as a welcome event: https://fusionauth.io/docs/v1/tech/apis/emails/#send-an-email

This is unfortunately a known issue. See https://github.com/FusionAuth/fusionauth-issues/issues/629 for some discussion. There are some workarounds in some situations (allow lists in Office 365) but no general workaround.

You could use the skipVerification parameter (set it to true) on the user or registration create statement, and then the https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email call with sendVerifyEmail set to false.

This would give you a verificationId you could use with this API call: https://fusionauth.io/docs/v1/tech/apis/users#verify-a-users-email

I figured it out…. I just had to put state.client_id in parens so it resolved them together.

[#assign clientId = (state.client_id?string)!"dafb6ef6-a2a8-4d34-9d69-59bfed3e31aa" /]

It looks like the issue was our mail server. We are using Mailgun SMTP service for our mail sending and this offers a tracking feature.

This tracking feature adds a invisible image to the html code in order to get request for stats. If I deactivate this feature, the HTML_IMAGE_ONLY_12 error is gone and the mail are no longer marked as SPAM. We don't have any issues with our other applications because sent emails are bigger in text content.

@dan I was trying to use the standard register interface from fusion. If I check that I want to use "username" for example, the registration form removes the email option. To circumvent and get both email and username I had to create my own register form.