Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions to better app.reacher.email #417

Open
solkmaaker opened this issue Jan 12, 2023 · 0 comments
Open

Suggestions to better app.reacher.email #417

solkmaaker opened this issue Jan 12, 2023 · 0 comments

Comments

@solkmaaker
Copy link

This is about app.reacher.email service, not the code.

  1. Do not use EHLO "gmail.com"
    EHLO has specific requierments:
    https://www.rfc-editor.org/rfc/rfc5321#section-4.1.4
    The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in [Section 2.3.5](https://www.rfc-editor.org/rfc/rfc5321#section-2.3.5). If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name.
    Since app.reacher.email is not gmail com, it may rise false negative where receiver server checks if EHLO matches your IP and since it does not, mail gets rejected.

  2. Do not use gmail.com address as envelope-from address when sending mail.
    gmail SPF policy is softfail. RFC7208 says:
    A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
    SHOULD NOT, is defined in RFC2119 as:
    SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
    And since that means that it is not mandatory to avoid rejection, some server do reject mail based solely on softfail policy.
    Same result here, due to softfail it may result as false negative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant