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

FYI Blacklisting #13

Open
SimeonC opened this issue Sep 10, 2014 · 2 comments
Open

FYI Blacklisting #13

SimeonC opened this issue Sep 10, 2014 · 2 comments

Comments

@SimeonC
Copy link

SimeonC commented Sep 10, 2014

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.

@jkantr
Copy link

jkantr commented Sep 26, 2017

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:

  1. Client initiation (HELO) should be on its own line (crlf)
  2. 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
  3. 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
  4. 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
Copy link

LinusU commented May 30, 2018

If anyone is interested, I've created a package that addresses all of those 4 points: https://github.com/LinusU/server-accepts-email

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

3 participants