however mail is received into a domain via POP from an SMTP server, so my original statement still stands unless you are authorized on the domain to send mail, either by way of IP from the domain or authenticated by some other means, you will not be able to connect to the SMTP server to send mail.
try randomly connecting to any SMTP server not on your domain and see if you can. If you find one the domain is open for relay. I guarantee you will not find many if any.
*** Sigh ***
This probably isn't worth a long argument....
Personally, I think you're wrong.
Mail is sent generally like this
Mail Sending Client (Outlook) --SMTP(YMMV)--> Your Domain Mail Server --SMTP--> Receiving Domain Mail Server --POP(YMMV)--> Mail Receiving Client(Outlook)
The bit where the Sending & Receiving mail servers talk to each other is almost always SMTP, and needs to support SMTP to remain compliant to the RFC in any case.
This is the bit you do, by pretending to be a sending mail server when you telnet to the Receiving Mail Server on port 25.
And if you want to PM me with your mail address, I'll connect to your domain's mail server, directly, and pretend to be Atilla The Hun and send you a mail
Any yes Nihil, you're absolutely spot on, with out law enforcement all this is pretty much worthless at proving anything.
February 6th, 2009, 06:41 PM
I know that even mail that makes it through 3 layers of spam filters is still something that I don't want. So using Mail (the default Mac mail app), I bounce it back as if I never received it. So even if it bounces back it might still be a good email addy.
May 3rd, 2013, 09:29 PM
If your use case is to validate a user's remote email address, this solution has a considerable flaw (similar to InternetAddress.validate()): EmailValidator considers firstname.lastname@example.org as a valid email addresses - which they are according to the RFC, but maybe not for user registration/contact form. – zillion1 Oct 5 '11 at 9:45