Allow unauthenticated SMTP

[Natureshadow]

This allows using an unauthenticated SMTP connection, if the gateway is running on the mailserver or in a network trusted by the mailserver.

[Natureshadow]

For this use case, I would suggest to handle that through a specific variable, e.g. SMTP_ANONYMOUS_AUTH=true (assuming that default is SMTP_ANONYMOUS_AUTH=false).

Then update the variable section of the documentation accordingly.

That depends on how you look at it. To be honest, no single software I have worked with has ever defaulted to authenticated SMTP, because SMTP traditionally works unauthenticated, and still normally does today in environments where the MX and the webserver are under local control.

But if you insist that you want to keep authentication the default, and make unauthenticated SMTP an exception, then going with a specific flag would probably be better.

My opinion is that hugo-mx-gateway should default to unauthenticated SMTP. I see no obvious reason not to.

[rchakode]

I understand your point of view.

Let's go with default as unauthenticated, but use a specific variable to indicate whether we want the authentication or not (SMTP_AUTHENTICATION_ENABLED=true, default false).

Rodrigue

For this use case, I would suggest to handle that through a specific variable, e.g. SMTP_ANONYMOUS_AUTH=true (assuming that default is SMTP_ANONYMOUS_AUTH=false). Then update the variable section of the documentation accordingly.

That depends on how you look at it. To be honest, no single software I have worked with has ever defaulted to authenticated SMTP, because SMTP traditionally works unauthenticated, and still normally does today in environments where the MX and the webserver are under local control.

But if you insist that you want to keep authentication the default, and make unauthenticated SMTP an exception, then going with a specific flag would probably be better.

My opinion is that hugo-mx-gateway should default to unauthenticated SMTP. I see no obvious reason not to.

[Natureshadow]

Let's go with default as unauthenticated, but use a specific variable to indicate whether we want the authentication or not (SMTP_AUTHENTICATION_ENABLED=true, default false).

That's the clean way, but I have one more point to consider:

This is a breaking change, because the default will change for existing configurations. Users who have credentials configured (that is, all users, up to 0.2.2) will suddenly see their setups stop working, or even lose mail if their mail servers decide to accept unauthenticated mail but then to different spam handling.

While the version is <1.0, according to semantic versioning, breaking changes are ok (or we could just bump to 1.0.0), but I think the benefits of a separate variable are too small to justify breaking existing setups.

[rchakode]

That's why in this case I would prefer to keep default as authenticated.

Use the variable SMTP_USERNAME for another purpose is not viable.

In short, let's keep the default behavior as authenticated (with a variable like SMTP_ANONYMOUS_AUTH=true, default false).

[rchakode]

This will preverse existing deployment while making possible to support unauthenticated in the future.

[rchakode]

@Natureshadow

Going back to this implementation with SMTP_AUTHENTICATION_ENABLED variable, it's possible to avoid breaking change by setting a default for SMTP_AUTHENTICATION_ENABLED in main.go

viper.SetDefault("SMTP_AUTHENTICATION_ENABLED", true)` in main.go)

Then in sendmail.go

    if viper.GetBool("SMTP_AUTHENTICATION_ENABLED") {
        smtpClientAuth := smtp.PlainAuth("",
            viper.GetString("SMTP_CLIENT_USERNAME"),
            viper.GetString("SMTP_CLIENT_PASSWORD"),
            smtpServerHost)
        if err = smtpClient.Auth(smtpClientAuth); err != nil {
            return fmt.Errorf("failed authenticating to smtp server (%s)", err)
        }
    }

Let's go with default as unauthenticated, but use a specific variable to indicate whether we want the authentication or not (SMTP_AUTHENTICATION_ENABLED=true, default false). That's the clean way, but I have one more point to consider: This is a breaking change, because the default will change for existing configurations. Users who have credentials configured (that is, all users, up to 0.2.2) will suddenly see their setups stop working, or even lose mail if their mail servers decide to accept unauthenticated mail but then to different spam handling. While the version is <1.0, according to semantic versioning, breaking changes are ok (or we could just bump to 1.0.0), but I think the benefits of a separate variable are too small to justify breaking existing setups.

[rchakode]

Dear @Natureshadow Do you still consider this PR?

[rchakode]

This is merged in # #16 with the suggested changes for SMTP_AUTHENTICATION_ENABLED

[Natureshadow]

Do you still consider this PR?

Yes, sorry, I was just lost in a different project the last week.

Thanks for finalising it!