Re: snddst

Hello Brad,

Am 07.01.2022 um 23:26 schrieb Brad Stone <bvstone@xxxxxxxxx>:

While it may work internally, and for some external, it won't work for all because a lot of systems are using reverse DNS lookups now, so if they can't map your IP to a domain they will reject the email and you'll never know.

Isn't there a log file? SNDDST uses MSF, which in turn uses SNADST. I dimly remember to have seen a somewhat cryptic transaction journal once.

That's why we use Mail Servers/Relays as a single point of sending emails.
Network folks set those up to avoid these issues, as well as auto spam
marking, etc.

Aside from that, they help counterfeit the restrictions posed by Outlook 365 SMTP service being abused as mail relay. A rather common pattern I observe from messages in this group.

For all readers: Sending and relaying email *properly* isn't an easy task and isn't limited to just do SMTP to the destination. Doing antispam and antivirus on the receiving side isn't a one-time effort, but a moving target. And sending mail over the internet is a constant challenge to stay ahead of other mailserver's antispam countermeasures. Never expect that today's working examples will still work tomorrow. Especially huge mail providers like Google and the likes are powerful enough to just enforce new restrictions, and if you complain, they say, "so what? Other's don't have issues."

Keywords for the interested IBM i fellow: Reverse-DNS, SMTP HELO, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-based Message Authentication, Reporting and Conformance (DMARC), Backscatter.

:wq! PoC (managing mailflow through Linux to our internal MS Exchange server for my employer)