jkantr
commented
7 years ago Time to comment on a 3 year old thread!
So the methodology itself isn't wrong, but some of the semantics are. Basically the flow needs to be updated to follow RFC 2821 more closely, as if you were writing an SMTP server. Some of this could be added to the docs maybe but the rest is just compliance stuff.
The most important thing to note, is that if you use this in its current state, your IP will 100% get added to a number of common block lists. Here's why:
- Client initiation (HELO) should be on its own line (crlf)
- HELO should not use the incoming mail server as its own identity, this is a trick used only by spam bots and will trigger a complaint (called 'impersonation') every time for a number of popular servers
- By default, the "send from" address should not be the "send to" address, this is also a form of impersonation and will trip a different ruleset
- The package destroys the socket before sending or receiving a QUIT action. This will always get you marked as a spam bot also. Needs a cleaner quit method.
1 and 4 are some easy fixes. Fixes 2 and 3 are harder, because even if you change these to your 'own' mail server address, it's going to fail reverse dns unless you actually set up a mail server (or at least take a few good steps)
tldr; change how you say helo and goodbye, don't impersonate the server or email address, set up a domain you can use as a mail server that will cleanly resolve to the same SP host you use (via rDNS), use a 'from' address that also matches
LinusU
Hi there, I've tried using this for email form validation. I've since discovered that was a very, very bad idea. If you misuse this method you can get quickly blacklisted by spam filters, this leads to some perfectly valid email addresses returning false due to the server's rejecting your IP via spam filter.
If I find a better way around this I'll come back and post it but it so far the only suggestion I've seen is to not do the telnet commands and just live with the regex and dns/mx record resolving.