I have a Delphi 7 application that I wrote that I have distributed to a partner living in a faraway place. The app uses the IndyDirect IdSMTP component to send mail to a mail server which I own. The mail server itself has no issues. The app worked fine until my friend moved. My friend ended up in a part of the world where his ISP blocks port 25. This prevents my Delphi app from sending email to my mail server.
The ISP said that they do permit port 587 as an alternative to port 25. My question is, is this a simple matter of changing the PORT property for the IdSMTP component from 25 to 587 and then recompiling the source code and giving my friend an updated .exe? Does anyone know if the mail server needs to be reconfigured in any way?
Thanks.
Yes, the mail server needs to be reconfigured. Right now it's listening on port 25; you need to configure it to listen on 587. This should be fairly simple with most off-the-shelf mail servers.
As an aside, I'd suggest putting the SMTP port into a configuration file that you read from in your Delphi code; then if the port changes again, all you have to do is update the config file rather than recompiling it and resending it to your friend. You could even get your friend to do it -- "Just open smtp.config and change '587' to 'xyz', then restart the program."
Related
Using AHKsock (AutoHotkey), I built a minimalistic client-server system with AHKsock_Connect, AHKsock_Send and AHKsock_Listen on both sides to communicate with each other. It works and I can send messages back and forth, if I connect to the server using localhost.
But I want the server to be accessible from everywhere. Shouldn't this be possible using my "external IP" which I can see # whatIsMyIP.com? Whenever someone tries to connect to the server on my computer, his/her connection will timeout/not work.
What is the IP of my server? How can others connect to it from anywhere? I assume there must be a simple solution to it, because the software itself seems to work: As stated above, connecting from the same computer to localhost will work.
Any help is much appreciated.
Did you forward the appropriate ports in your router/firewall? The IP should be correct.
This was the solution, I did something wrong in my router
I need to troubleshoot an issue by trying to block port 1935 connections to remote servers for a home computer. Note, 1935 is the default port for Flash Media Server's RTMP protocol. My home router is a Netgear one. I followed their instructions by creating a 'Service' in which port 1935 was 'always blocked' and then added that service to the 'Outgoing' part of the Firewall Rules of the router. But my testing still shows a successful connection from a Flash client to port 1935.
I thought there might be some way in the Windows 7 firewall but don't see any?
Any idea?
Thanks.
Try restarting the router. Many firewall changes don't take effect until the router is rebooted.
The correct answer is what I already said in my Comment to #Matt and as per my screen cap:
https://docs.google.com/open?id=0BxaCdcZpiglQQ0ZPbERzS0pPWFE
I had the settings right in the router: Port 1935 was indeed blocked. However, my test Flash application still reported rtmp, which made me think it was still port 1935. It was actually rtmp over port 443, as I later found out.
So if someone wants to block certain remote ports in a Netgear router then they can follow the steps I took: Create a 'Service' with the desired port; then add that Service to the Firewall Rules 'Outgoing' part, per my screen cap.
Thank you, Matt, for your help!
I have built several applications in delphi using the indy components suite(version 10.5.2 i think) and they all are working. I have just finished setting up the POP3server and it works locally. I can see mail sent locally on there. I have been using "localhost" as my hostname. However, i want to graduate to a higher level of function. I want to be able to receive email from the internet such from msn, gmail, yahoo ... The problem is I don't know how to do this. What address should I be using inorder to do this? So far "myhouse#localhost" has been working but only internally; can't seem to get external mail in there. Is it possible to receive mail like this? Thanks.
You need to register a domain, and then setup its DNS records (in particular, its MX records) to point to your server machine. That way, when an email is destined for any "#yourdomain" address by any sending service, it will be routed to your server machine (which needs to run an SMTP server to receive emails - POP3 is for downloading emails from your mailbox, not for putting emails into it). If your server does not have a static IP, then you need to use a service like DynDNS to mange the DNS records for you so they can account for your dynamic IP whenever it changes.
"The Internet" doesn't use POP3 to send and receive email, it uses SMTP. Here's how email "flows" from the sending computer to the receiving computer:
Server needs to send email to address: myhome#localhost. The first thing it does is isolate the server name, that's the part after "#". Next it uses DNS to lookup the SERVER IP for the computer that's supposed to receive email for the given domain. DNS contains a special record for this purpose, it's called the "MX" record. You can use command line tools like dig on Linux or nslookup on Windows to find this address, or you can use an online tool like the one found at http://www.mxtoolbox.com/ (google found this site, I assume there are many others!).
If you try to locate the MX record for your "localhost" domain you'll obviously discover it's not possible, because it's not a fully-qualified name. You first need to get yourself an domain name, so you can register a MX record!
Things you need in order to RECEIVE email
Need an "real" IP address. Servers outside your local network need to contact your server, and they obviously need a way to do it. Make sure no routers along the way block SMTP ports.
You need to register an domain name, add a MX record and point it to your "real" IP address.
Need to run SMTP server software on your box. You can use Indy components to write one.
Things you need in order to SEND email
Theoretically sending email with SMTP is the easy part. You just contact the responsible server using SMTP and send email, that's the way the protocol works: any computer in the world may send email to any SMTP server.
Practically sending email is the most difficult thing you'd have to do, mostly because foreign SMTP servers don't trust you (ever heard of SPAM?). Here are some of the things you might need to do so foreign SMTP servers accept email from you. There's no definitive list because the protocol itself doesn't include a clear authentication mechanism, so every big SMTP server out there uses it's own heuristics to decide rather to accept email from you or not. You'll find yahoo especially fun!
You need to have REVERSE DNS for the IP you're using to send email.
You need to send from one of the SMTP servers listed in DNS as your MX servers.
Your DNS records need to have long TTL (this rules out Dynamic DNS services)
Many other things...
What people usually do?
eMail is hard, there's a surprisingly small number of full SMTP servers available for your own server: Exchange, Notes, Postfix, QMail, Sendmail. They're all notoriously difficult to configure. Most people would use hosted mail services, some people would use the SMTP services provided by the ISP, and very few would install one of the mentioned services.
If you really want to write your own SMTP server go ahead, but you might want to install one of the ready-made ones before, to get a bit of eMail and DNS experience. The Linux ones are cheap to install and may also help with development (you don't want to send too much bad email to your free yahoo address, you might get blacklisted!)
POP3 is a protocol to read email from a mailbox. The TidPOP3Server component implements a POP3 server (and AFAIK it has no host property to set...), while TidPOP3 implements a POP3 client. To read mail from GMail or any POP3 server you need a TidPOP3 component. The hostname to set is the DNS name the service instructs you to use (i.e. pop3.mydomain.com).
How do I accomplish this? The SMTP class throws error on dev machine about not finding an SMTP server. Is there a way to test sending emails on development machine?
Shawn,
Straight from my web.config:
<smtp deliveryMethod="SpecifiedPickupDirectory">
<network host="ignored" />
<specifiedPickupDirectory pickupDirectoryLocation="c:\email_c#" />
</smtp>
this works fine insofar as being able to review the 'emails' that get saved into the pickupDirectoryLocation directory.
Give it a try...
You can dump the files on disk, by configuring System.Net.Mail.SmtpClient to use a deliveryMethod of type SpecifiedPickupDirectory, I found an example on SO
I know this is an old thread, but I just stumbled upon this service:
http://mailtrap.io/
Which is friggin brilliant. It serves as a dummy SMTP server for your app, and doesn't actually send the emails, but allows you to easily view them in the browser (or via API).
It's killer.
There's a couple possible reasons for this.
1) Is your code configured to use local SMTP server during development and you've upgraded to windows 7? There's no longer a SMTP server available on your localhost. Find and download smtp4dev to allow your localhost to trap the sent Emails.
2) If you are using a remote SMTP server, check your windows firewall to confirm that you are allowed to send outgoing mail. If you are, then confirm that your machine/username has rights to send mail via that server. A quick telnet:25 to the server should let you know if your connection is refused or not.
Assuming by "test sending emails" you mean sending test emails instead of formal/unit testing, I like to use smtp4dev:
http://smtp4dev.codeplex.com/
As the page explains, it's a dummy SMTP server, basically intercepting your outgoing messages from your app, allowing you to examine those messages and make sure everything works as you expect. It's a Windows app, which hopefully isn't an issue if you're developing for ASP.NET.
I usually do this by creating a wrapper class for the SmtpClient, then mocking out the wrapper in my tests. This removes the actual mail client/server dependencies from my unit tests. The wrapper itself is relatively thin so I don't feel the need to create tests for it. Usually I do my integration level testing for things like this as exploratory tests in my staging environment. The staging environment typically uses a production mail server, but with "fake" data -- e.g., customer email addresses replaced with my own.
Having said that, I would expect the client to work without errors even on your development system unless your mail server is protected by a firewall or something that would prevent your dev system talking to it. Can you give more detail on what the error you are experiencing?
Without seeing the exception there's not much we can do. As long as the details on your dev machine are pointing to a proper smtp server and have the correct credentials then your code won't be the issue and you should look further down the chain. I had an exception of the target machine refusing the request despite everything else being right. After spending ages double and triple checking the credentials, sending from our server etc I tracked the bug down to McAfee blocking email port 25...
A rails application in production should use smtp or sendmail to send mails?
SMTP is the protocol that is used by nearly all Internet hosts to send mail. This protocol is spoken by sendmail. Sendmail determines where to send your message and how.
Some mail programs (most, today) will connect directly to a mail server and speak SMTP to it. However, the "traditional" method - and arguable the better method - is to let sendmail do it.
There are two reasons for this: 1) nearly every program in UNIX that does what sendmail does is designed to be a drop-in replacement (this includes Postfix and Exim for instance); and 2) sendmail or its replacement was designed to handle mail and nothing else - by using sendmail you don't have to design a SMTP client.
The Mutt email client for UNIX is one email client that still refuses to talk SMTP directly to a mail server; a good (technical) description is on the wiki.
If you have a choice (on UNIX anyway) of talking SMTP directly or using sendmail, use sendmail - especially on servers.
As NDP already mentioned, they both work fine - that is, if your volume of messages doesn't exceed a certain amount.
For example, if your application can talk SMTP to either the local SMTP server (on IP 127.0.0.1, Port 25) or a server in the same subnet (i.e., over a low-latency link), and that server does not use any content filters before it queues a message, you will usually be able to submit a lot more mails over SMTP in a shorter time.
A useful link for Postfix may be General Mail Delivery Performance Tips - note the quote saying
Submit mail via SMTP instead of /usr/sbin/sendmail.
However, on modern hardware, if you don't plan to submit more than about 10 messages per second, you shouldn't notice any real difference.
Your question is incorrect - SMTP stands for Simple Mail Transfer Protocol whereas sendmail is the software piece to send the mail using this protocol.
Use sendmail.
They both will work fine. Action Mailer supports both.
I have used SMTP on several projects successfully. My sense was that this was a little more "standard", but I may be wrong.
I haven't used sendmail. My concern would be that it may be harder to set up in a development environment if you aren't developing directly on Unix/Linux. Where you can talk directly to any SMTP server -- even a remote one, -- you would have to install sendmail on the rails machine to get it to work.
The main problem I run into with email is sending messages asynchronously. Without a local SMTP server, a local sendmail instance is going to be more performant.
Either way, it looks pretty easy to switch if you decide you picked wrong.