Python SMTP ਰੀਲੇ ਸਬਮਿਸ਼ਨ: 587 'ਤੇ STARTTLS ਜਾਂ 465 'ਤੇ TLS?

ਦੋਵੇਂ ਕਨੈਕਸ਼ਨ ਢੰਗ ਇੱਕੋ ਸੁਨੇਹਾ ਇੱਕੋ ਰੀਲੇ ਖਾਤੇ ਤੱਕ ਪਹੁੰਚਾਉਂਦੇ ਹਨ, ਅਤੇ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ TLS ਕਿੱਥੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕੀ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਨਹੀਂ। ਇੱਕ ਸਾਫ਼ ਟੈਕਸਟ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ ਅਤੇ ਬੈਂਡ ਦੇ ਅੰਦਰ ਹੀ ਅੱਪਗ੍ਰੇਡ ਹੁੰਦਾ ਹੈ; ਦੂਜਾ ਪਹਿਲੇ ਬਾਈਟ ਤੋਂ ਹੀ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਹੁੰਦਾ ਹੈ। ਇਹੀ ਇੱਕ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਖ਼ਤ ਰੀਲੇ ਨੀਤੀ ਕੀ ਸਵੀਕਾਰ ਕਰੇਗੀ, ਵਿਚਕਾਰਲਾ ਜੰਤਰ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਗਲਤੀ ਸੁਨੇਹਾ ਤੁਸੀਂ ਅੱਧਾ ਦਿਨ ਪੜ੍ਹਦੇ ਰਹੋਗੇ। ਨਿੱਜੀ ਨੈੱਟਵਰਕ 'ਤੇ ਚੱਲ ਰਹੀ ਐਪਲੀਕੇਸ਼ਨ ਜਦੋਂ ਅੰਦਰੂਨੀ ਸਬਮਿਸ਼ਨ ਸੇਵਾ ਨੂੰ ਸੁਨੇਹਾ ਸੌਂਪਦੀ ਹੈ, ਤਦ ਮੈਂ ਇਹਨਾਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਵੇਂ ਚੋਣ ਕਰਦਾ ਹਾਂ, ਇਹ ਰਿਹਾ।

ਦੋਵੇਂ ਢੰਗ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦੇ ਹਨ

ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਕੰਮ ਇੱਕੋ ਹੈ: ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਖਾਤੇ ਵਜੋਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰੋ, ਮਨਜ਼ੂਰ ਭੇਜਣ ਵਾਲੇ ਦਾ ਨਾਮ ਦਿਓ, ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਅਤੇ ਉਡੀਕ ਕਰੋ ਕਿ ਰੀਲੇ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈ ਲਵੇ। ਜੋ ਬਦਲਦਾ ਹੈ ਉਹ ਕਾਰਵਾਈਆਂ ਦਾ ਕ੍ਰਮ ਹੈ। ਪੋਰਟ 587 ਸਾਫ਼ ਟੈਕਸਟ SMTP ਸੈਸ਼ਨ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, EHLO ਜਵਾਬ ਵਿੱਚ STARTTLS ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਮੰਗੇ ਤਾਂ ਹੀ ਅੱਪਗ੍ਰੇਡ ਹੁੰਦਾ ਹੈ। ਪੋਰਟ 465 ਕੋਈ ਵੀ SMTP ਹੁਕਮ ਬੋਲਣ ਤੋਂ ਪਹਿਲਾਂ TLS ਹੈਂਡਸ਼ੇਕ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।

ਸਬਮਿਸ਼ਨ ਅਤੇ ਰੀਲੇ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਇਸ ਲਈ ਪੋਰਟ ਨੰਬਰ ਬਦਲੇ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਆਦਤਾਂ ਨਹੀਂ ਹਨ। RFC 6409 ਸੁਨੇਹਾ ਸਬਮਿਸ਼ਨ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਸੇਵਾ ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ RFC 8314 ਉਸ ਅੰਤਰਨਿਹਿਤ-TLS ਰੂਪ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਰੀਲੇ 465 'ਤੇ ਪੇਸ਼ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਰੀਲੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਦਸਤਾਵੇਜ਼ ਪਿਛਲੇ ਰੁਜ਼ਗਾਰਦਾਤਾ ਤੋਂ ਮਿਲੀ ਕਿਸੇ ਵੀ ਤਰਜੀਹ ਤੋਂ ਉੱਪਰ ਹੈ।

587 'ਤੇ STARTTLS ਤੁਹਾਨੂੰ ਕੀ ਦਿੰਦਾ ਹੈ

ਅੱਪਗ੍ਰੇਡ SMTP ਗੱਲਬਾਤ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਰੀਲੇ ਇਸ ਦਾ ਐਲਾਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਇਸ ਤੋਂ ਬਿਨਾਂ ਅੱਗੇ ਵਧਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। Python ਵਿੱਚ, ਸਰਵਰ ਉਹ ਐਕਸਟੈਂਸ਼ਨ ਪੇਸ਼ ਨਾ ਕਰਨ 'ਤੇ starttls() ਅਪਵਾਦ ਸੁੱਟਦਾ ਹੈ, ਜੋ ਡਾਊਨਗ੍ਰੇਡ ਦੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਚੁੱਪ ਸਾਫ਼-ਟੈਕਸਟ ਲੌਗਇਨ ਦੀ ਥਾਂ ਦਿੱਸਣ ਵਾਲੀ ਅਸਫਲਤਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਵਿਵਹਾਰ ਇਸ ਢੰਗ ਦਾ ਮੁੱਖ ਤਰਕ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ ਇਤਫ਼ਾਕ ਨਾਲ ਨਹੀਂ, ਜਾਣ-ਬੁੱਝ ਕੇ ਭਰੋਸਾ ਕਰਨਾ ਢੁਕਵਾਂ ਹੈ।

ਖੁੱਲ੍ਹ ਦੀ ਖਿੜਕੀ ਛੋਟੀ ਪਰ ਅਸਲੀ ਹੈ: ਸ਼ੁਰੂਆਤੀ EHLO ਅਦਲ-ਬਦਲ ਪੜ੍ਹਨਯੋਗ ਹੈ, ਅਤੇ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਵੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ ਢੋਂਦਾ। ਐਪਲੀਕੇਸ਼ਨ ਸਬਨੈੱਟ ਅਤੇ ਅੰਦਰੂਨੀ ਰੀਲੇ ਵਿਚਕਾਰ ਨਿੱਜੀ ਰਾਹ 'ਤੇ ਉਹ ਖਿੜਕੀ ਆਮ ਤੌਰ 'ਤੇ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦੀ ਹੈ। ਜਿਸ ਰਾਹ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ, ਉੱਥੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕੁਝ ਟੀਮਾਂ ਦੂਜੇ ਢੰਗ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀਆਂ ਹਨ।

STARTTLS ਸਮਰੱਥਾ ਹਟਾਉਣ ਵਾਲਾ ਇੰਟਰਸੈਪਸ਼ਨ ਜੰਤਰ ਅਸਫਲ ਸਬਮਿਸ਼ਨ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਫ਼ਾਲਬੈਕ ਨਹੀਂ। ਇਹੀ ਉਹ ਨਤੀਜਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਵੀ ਹੈ ਕਿ ਰਾਹ 'ਤੇ ਕੁਝ SMTP ਨੂੰ ਮੁੜ ਲਿਖ ਰਿਹਾ ਹੈ।

465 'ਤੇ ਅੰਤਰਨਿਹਿਤ TLS ਕੀ ਬਦਲਦਾ ਹੈ

ਸਾਫ਼ ਟੈਕਸਟ ਦਾ ਕੋਈ ਪੜਾਅ ਹੀ ਨਹੀਂ। ਸਾਕਟ ਖੁੱਲ੍ਹਦਿਆਂ ਹੀ ਕਲਾਇੰਟ TLS ਹੈਂਡਸ਼ੇਕ ਕਰਦਾ ਹੈ, ਆਪਣੇ ਭਰੋਸਾ ਭੰਡਾਰ ਦੇ ਸਾਮ੍ਹਣੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ EHLO, AUTH ਅਤੇ ਸੁਨੇਹੇ ਦਾ ਅਦਲ-ਬਦਲ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਸੈਸ਼ਨ ਨੂੰ ਡਾਊਨਗ੍ਰੇਡ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿਉਂਕਿ ਗੱਲਬਾਤ ਲਈ ਸਾਫ਼-ਟੈਕਸਟ ਹਾਲਤ ਹੀ ਨਹੀਂ, ਅਤੇ ਇਸ ਨਾਲ ਇੰਟਰਸੈਪਸ਼ਨ ਅਸਫਲਤਾਵਾਂ ਦਾ ਪੂਰਾ ਵਰਗ ਹਟ ਜਾਂਦਾ ਹੈ।

ਇਹ ਅਦਲ-ਬਦਲ ਨਿਦਾਨਯੋਗਤਾ ਹੈ। 465 'ਤੇ ਸਾਫ਼-ਟੈਕਸਟ SMTP ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਰੀਲੇ, ਜਾਂ ਗਲਤ ਸਰਟੀਫਿਕੇਟ ਨਾਮ ਨਾਲ TLS ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਲੋਡ ਬੈਲੰਸਰ, ਹੈਂਡਸ਼ੇਕ 'ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਮੇਲ ਗਲਤੀ ਦੀ ਥਾਂ ਤੁਹਾਨੂੰ SSL ਗਲਤੀ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਸਮੱਸਿਆ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹੇਠਾਂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਿੰਨਾ ਵੀ ਸੁਨੇਹਾ ਬਣਾਇਆ ਜਾਵੇ, ਉਹ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ।

ਇੱਕ ਸਬਮਿਸ਼ਨ ਫੰਕਸ਼ਨ, ਦੋ ਟਰਾਂਸਪੋਰਟ

ਕੋਡ ਦੋਵਾਂ ਢੰਗਾਂ ਵਿਚਕਾਰ ਘੱਟ ਹੀ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਚੋਣ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਸੁਵਿਧਾ ਨਹੀਂ ਸਗੋਂ ਰੀਲੇ ਨੀਤੀ ਤੋਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਹਿਲਾਂ ਸੈਟਿੰਗਾਂ ਬਰਾਮਦ ਕਰੋ, ਫਿਰ ਇੱਕ ਸਕ੍ਰਿਪਟ ਚਲਾਓ ਜੋ ਸੰਰਚਿਤ ਪੋਰਟ ਤੋਂ ਟਰਾਂਸਪੋਰਟ ਚੁਣਦੀ ਹੈ।

export SMTP_HOST=smtp.relay.internal
export SMTP_PORT=587
export SMTP_USER=svc-notify
export [email protected]
export [email protected]
export SMTP_PASSWORD="$(cat /run/secrets/smtp_password)"

import os, smtplib, ssl
from email.message import EmailMessage

ctx = ssl.create_default_context()
msg = EmailMessage()
msg["From"] = os.environ["MAIL_FROM"]
msg["To"] = os.environ["MAIL_TEST_TO"]
msg["Subject"] = "relay submission test"
msg.set_content("One authorized test message from the app.")

host = os.environ["SMTP_HOST"]
port = int(os.environ.get("SMTP_PORT", "587"))

if port == 465:
    client = smtplib.SMTP_SSL(host, port, context=ctx, timeout=15)
else:
    client = smtplib.SMTP(host, port, timeout=15)
    client.ehlo()
    client.starttls(context=ctx)
    client.ehlo()

with client:
    client.login(os.environ["SMTP_USER"], os.environ["SMTP_PASSWORD"])
    refused = client.send_message(msg)

print("refused:", refused)

create_default_context() ਲੜੀ ਅਤੇ ਹੋਸਟਨਾਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਿੱਜੀ CA ਨੂੰ ਭਰੋਸਾ ਭੰਡਾਰ ਵਿੱਚ ਸਥਾਪਿਤ ਕਰਨਾ ਪਵੇਗਾ, ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਵਾਲੇ ਸੰਦਰਭ ਨਾਲ ਬਚਣਾ ਨਹੀਂ। send_message() ਰੀਲੇ ਵੱਲੋਂ ਰੱਦ ਕੀਤੇ ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਦਾ ਸ਼ਬਦਕੋਸ਼ ਵਾਪਸ ਕਰਦਾ ਹੈ; ਖਾਲੀ ਸ਼ਬਦਕੋਸ਼ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਸ ਨੇ ਸਾਰਿਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ। ਪੰਦਰਾਂ ਸਕਿੰਟ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ, ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਲਈ ਟਿਊਨ ਕੀਤਾ ਮੁੱਲ ਨਹੀਂ।

ਪਾਸਵਰਡ ਨੂੰ ਇਮੇਜ ਤੋਂ ਅਤੇ ਲੌਗ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਰਨਟਾਈਮ 'ਤੇ ਮਾਊਂਟ ਕੀਤਾ ਅਤੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਪੜ੍ਹਿਆ ਭੇਤ ਠੀਕ ਹੈ; ਵਾਤਾਵਰਨ ਨੂੰ ਲੌਗ ਲਾਈਨ ਵਿੱਚ ਗੂੰਜਾਉਣਾ ਠੀਕ ਨਹੀਂ, ਅਤੇ AUTH ਅਦਲ-ਬਦਲ ਦਾ ਡੀਬੱਗ ਨਿਸ਼ਾਨ ਵੀ ਨਹੀਂ।

ਆਦਤ ਨਾਲ ਨਹੀਂ, ਰੀਲੇ ਨੀਤੀ ਅਤੇ ਰਾਹ ਨਾਲ ਚੁਣੋ

ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਪਹਿਲੀ, ਰੀਲੇ ਅਸਲ ਵਿੱਚ ਕੀ ਐਲਾਨ ਕਰਦਾ ਹੈ: ਸਿਰਫ਼ 587 'ਤੇ STARTTLS ਨਾਲ ਸੁਣਨ ਵਾਲੀ ਸੇਵਾ 465 'ਤੇ ਪਹੁੰਚਾਈ ਨਹੀਂ ਜਾ ਸਕਦੀ, ਚਾਹੇ ਤੁਸੀਂ ਅੰਤਰਨਿਹਿਤ TLS ਨੂੰ ਕਿੰਨਾ ਵੀ ਪਸੰਦ ਕਰੋ। ਦੂਜੀ, ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਰੀਲੇ ਵਿਚਕਾਰਲਾ ਰਾਹ ਪੜ੍ਹਨਯੋਗ EHLO ਅਦਲ-ਬਦਲ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਹੈ। ਤੀਜੀ, ਕੀ ਵਿਚਕਾਰ ਕੁਝ SMTP ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਜਾਂ ਪ੍ਰੌਕਸੀ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਡਾਊਨਗ੍ਰੇਡ ਖ਼ਤਰਾ ਸਿਧਾਂਤਕ ਹੈ ਜਾਂ ਅਸਲੀ।

ਜਦੋਂ ਰੀਲੇ ਦੋਵੇਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਮੈਂ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਚੱਲਣ ਵਾਲੀ ਸੇਵਾ ਲਈ 465 ਲੈਂਦਾ ਹਾਂ ਅਤੇ ਪਹਿਲੀ ਤੈਨਾਤੀ ਨੂੰ ਕੋਈ ਵਿਅਕਤੀ ਦੇਖ ਰਿਹਾ ਹੋਵੇ ਉਸ ਸੇਵਾ ਲਈ 587, ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਅਸਫਲਤਾ ਦੇ ਸੁਨੇਹੇ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਉਹ ਤਰਜੀਹ ਮੇਰੀ ਹੈ ਅਤੇ ਉਹ ਨੀਤੀ ਨਹੀਂ ਹੈ।

ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਪੋਰਟ, ਭਰੋਸਾ ਸਮੱਗਰੀ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਦਾ ਡੋਮੇਨ ਤੈਨਾਤੀ ਨਾਲ ਦਰਜ ਕਰੋ। ਫਿਰ ਇੱਕ ਅਧਿਕਾਰਤ ਟੈਸਟ ਸੁਨੇਹਾ ਭੇਜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੀਲੇ ਨੇ ਉਸ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ, ਸਬਮਿਸ਼ਨ ਨਤੀਜਾ ਅਤੇ ਬਾਅਦ ਦੀ ਕੋਈ ਵੀ ਡਿਲੀਵਰੀ ਰਿਪੋਰਟ ਵੱਖਰੇ ਰਿਕਾਰਡ ਵਜੋਂ ਰੱਖੋ। ਰੀਲੇ ਨੂੰ ਸਫਲ ਹਸਤਾਂਤਰਣ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਅੰਤ ਹੈ, ਸੁਨੇਹੇ ਦੇ ਇਨਬਾਕਸ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਸਬੂਤ ਨਹੀਂ।