Python SMTP ರಿಲೇ ಸಲ್ಲಿಕೆ: 587 ನಲ್ಲಿ STARTTLS ಅಥವಾ 465 ನಲ್ಲಿ TLS?

ಎರಡೂ ಸಂಪರ್ಕ ವಿಧಾನಗಳು ಒಂದೇ ಸಂದೇಶವನ್ನು ಒಂದೇ ರಿಲೇ ಖಾತೆಗೆ ತಲುಪಿಸುತ್ತವೆ, ಮತ್ತು ವ್ಯತ್ಯಾಸ TLS ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿದೆ, ಏನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿಲ್ಲ. ಒಂದು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ತೆರೆದು ಬ್ಯಾಂಡ್ ಒಳಗೆ ಮೇಲ್ದರ್ಜೆಗೇರಿಸುತ್ತದೆ; ಇನ್ನೊಂದು ಮೊದಲ ಬೈಟ್ನಿಂದಲೇ ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿದೆ. ಆ ಒಂದೇ ವ್ಯತ್ಯಾಸವು ಕಟ್ಟುನಿಟ್ಟಾದ ರಿಲೇ ನೀತಿ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮಧ್ಯವರ್ತಿ ಸಾಧನ ಏನನ್ನು ಗಮನಿಸಬಹುದು, ಮತ್ತು ಯಾವ ದೋಷ ಸಂದೇಶವನ್ನು ನೀವು ಅರ್ಧ ದಿನ ಓದುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ ಆಂತರಿಕ ಸಲ್ಲಿಕೆ ಸೇವೆಗೆ ಸಂದೇಶವನ್ನು ಒಪ್ಪಿಸಿದಾಗ ನಾನು ಈ ಎರಡರ ನಡುವೆ ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಎರಡೂ ವಿಧಾನಗಳು ನಿಜವಾಗಿ ಎಲ್ಲಿ ಬೇರ್ಪಡುತ್ತವೆ

ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕೆಲಸ ಒಂದೇ: ಅನುಮೋದಿತ ಖಾತೆಯಾಗಿ ದೃಢೀಕರಿಸಿ, ಅನುಮತಿಸಿದ ಕಳುಹಿಸುವವರನ್ನು ಹೆಸರಿಸಿ, ಸ್ವೀಕರಿಸುವವರನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ಮತ್ತು ರಿಲೇ ಜವಾಬ್ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುವವರೆಗೆ ಕಾಯಿರಿ. ಬದಲಾಗುವುದು ಕಾರ್ಯಾಚರಣೆಗಳ ಕ್ರಮ. ಪೋರ್ಟ್ 587 ಸ್ಪಷ್ಟ ಪಠ್ಯದ SMTP ಅಧಿವೇಶನವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, EHLO ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ STARTTLS ಘೋಷಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೇಳಿದರೆ ಮಾತ್ರ ಮೇಲ್ದರ್ಜೆಗೇರಿಸುತ್ತದೆ. ಪೋರ್ಟ್ 465 ಯಾವುದೇ SMTP ಆದೇಶ ಹೇಳುವ ಮೊದಲು TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ನಿರೀಕ್ಷಿಸುತ್ತದೆ.

ಸಲ್ಲಿಕೆ ಮತ್ತು ರಿಲೇ ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳು, ಆದ್ದರಿಂದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಅಭ್ಯಾಸಗಳಲ್ಲ. RFC 6409 ಸಂದೇಶ ಸಲ್ಲಿಕೆಯನ್ನು ತನ್ನದೇ ಸೇವೆಯಾಗಿ ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು RFC 8314 ಹೆಚ್ಚಿನ ಆಧುನಿಕ ರಿಲೇಗಳು 465 ನಲ್ಲಿ ಒದಗಿಸುವ ಗುಪ್ತ-TLS ರೂಪಾಂತರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ರಿಲೇ ಎರಡರಲ್ಲಿ ಒಂದನ್ನು ದಾಖಲಿಸಿದರೆ, ಆ ದಾಖಲೆ ಹಿಂದಿನ ಉದ್ಯೋಗದಾತರಿಂದ ಪಡೆದ ಯಾವುದೇ ಆದ್ಯತೆಗಿಂತ ಮೇಲುಗೈ ಸಾಧಿಸುತ್ತದೆ.

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, ಕೇವಲ ವೈಫಲ್ಯದ ಸಂದೇಶಗಳು ಬೇರೆ ಬೇರೆ ಪದರಗಳನ್ನು ಸೂಚಿಸುವುದರಿಂದ. ಆ ಆದ್ಯತೆ ನನ್ನದು ಮತ್ತು ಅದು ನೀತಿಯಲ್ಲ.

ನೀವು ಏನೇ ಆಯ್ಕೆ ಮಾಡಿದರೂ, ಪೋರ್ಟ್, ವಿಶ್ವಾಸ ಸಾಮಗ್ರಿ ಮತ್ತು ಕಳುಹಿಸುವವರ ಡೊಮೇನ್ ಅನ್ನು ನಿಯೋಜನೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ. ನಂತರ ಒಂದು ಅಧಿಕೃತ ಪರೀಕ್ಷಾ ಸಂದೇಶ ಕಳುಹಿಸಿ ಮತ್ತು ರಿಲೇ ಅದನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಸಲ್ಲಿಕೆ ಫಲಿತಾಂಶ ಮತ್ತು ಯಾವುದೇ ನಂತರದ ವಿತರಣಾ ವರದಿಯನ್ನು ಪ್ರತ್ಯೇಕ ದಾಖಲೆಗಳಾಗಿ ಇರಿಸಿ. ರಿಲೇಗೆ ಯಶಸ್ವಿ ಹಸ್ತಾಂತರ ಅಪ್ಲಿಕೇಶನ್ ಜವಾಬ್ದಾರಿಯ ಅಂತ್ಯ, ಸಂದೇಶ ಇನ್ಬಾಕ್ಸ್ ತಲುಪಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.