it initiates an email to an internal mail server using well known SMTP TCP port #25. What does it mean? What kind of emails can I send according to this statement?
Summary
Port 25 is the "well-known port" used for SMTP (Simple Mail Transfer Protocol) by insecure email servers to receive emails that are to be delivered to
[email protected] addresses.
You can send any kind of email, as the SMTP is an ASCII protocol; everything you need to know is more or less in RFCs 5322 and 6854, although most of that detail will be covered by the PLC email-handling instruction.
Details
Port 25
The following contains generalizations, but the basic thrust should be reasonably accurate.
All TCP/IP services use a client/server model. The client initiates a connection to a server and a dialogue takes place according to a protocol. Every connection is defined by four parameters: the server IP address; the server port; the client IP address; the client port. The client knows the server's IP address and its own IP address, and usually picks a client port more or less at random. The syntax, grammar and flow of the protocol is dependent on the service being requested. The way to connect to a particular service, in this case SMTP to send email, is to connect to the SMTP server host using the well-known port for that service, in this case port 25.
The reason for this is that an MTA (Mail Transfer Agent), the code and process that provides the SMTP service, is very complicated: of all the O'Reilly books about the various pieces of computer technology, the SMTP/MTA tome about how to configure an MTA to route emails is one of the few that can stop a bullet. The configuration required for an email client to initiate an email and pass it to an MTA is far simpler and suitable for most email users: it needs only the server hostname, port (or service) and any authentication information.
Any service can be supplied on any port - the RFCs mentioned above do not mention specific ports for SMTP - but the Internet runs on many explicit and implicit agreements, one of which is a list of "well-known ports" for well-known services, one of which ports was port 25 for SMTP servers. There was also port 465 which was encrypted SMTP and now 587 or 2525 are used. For example, Ports 80 and 443 are insecure HTTP and secure HTTPS i.e. web services; port 44818 is the well-known port for Ethernet/IP.
Currently Port 25 is obsolete
on the "Internet" in general, as an anti-spam measure, to the point that many ISPs block outgoing traffic on port 25, but that does not stop any installation from running a private server behind a firewall, at port 25 to handle emails from trusted hosts e.g. PLCs behind that same firewall. How much sophistication in an SMTP server can be used, or how little can be gotten away with , in a private server to handle PLC-originating email will depend on the PLC; the server itself will likely be a relay MTA that will use a higher level of sophistication (encryption, authentication, etc.), although still possibly using the SMTP protocol.
Bottom line, contact the IT department and find out what SMTP servers are available and what services (ports and protocols) they offer. If there is no overlap with the PLC, something like a RaspberryPI running a minimal MTA/relay/SMTP server should work, but it will not be for the faint of heart.
Sending email
The SMTP protocol goes something like the following, with the client commands in blue, and with comments in red:
Code:
> [B][COLOR=blue]telnet mail.local.domain 25[/COLOR][/B]
...
[COLOR=Blue][B]HELO me[/B][/COLOR][COLOR=blue][B] [COLOR=red]<== Start protocol dialogue[/COLOR][/B][/COLOR]
250 MAIL mail.local.domain Hello your.host.name (1.2.3.4)
[COLOR=blue][B]MAIL FROM: <[email protected]> [COLOR=red]<== Start a new email from this address[/COLOR][/B][/COLOR]
250 OK
[COLOR=blue][B]RCPT TO: <[email protected]> [COLOR=red]<== First recipient[/COLOR][/B][/COLOR]
250 OK
[COLOR=blue][B]RCPT TO: <[email protected]> [COLOR=red]<== Second recipent[/COLOR][/B][/COLOR]
[COLOR=blue][B]DATA[/B][/COLOR][COLOR=Blue][B][COLOR=Red] <== Start email content[/COLOR][/B][/COLOR]
[COLOR=blue][B]Subject: PLCs are great[/B][/COLOR]
[COLOR=Blue][B]X-Other-Email-Header: blah blah[/B][/COLOR]
[COLOR=Blue][B][COLOR=Red] <== Blank line indicates end of headers, and start if enail body[/COLOR][/B][/COLOR]
[COLOR=Blue][B]Check out WWW.PLCTalk.net![/B][/COLOR][COLOR=Blue][B][COLOR=Red] <== Blan[/COLOR][/B][/COLOR]
[COLOR=Blue][B].[/B][/COLOR][COLOR=Blue][B][COLOR=Red] <== Single full stop indicates end of email content[/COLOR][/B][/COLOR]
[COLOR=Blue][COLOR=Black]<some response, probably OK>[/COLOR][B][COLOR=Red]
[/COLOR][/B][/COLOR]
[COLOR=Blue][B]QUIT[/B][/COLOR][COLOR=Blue][B][COLOR=Red] <== End protocol dialogue[/COLOR][/B][/COLOR]
<telnet session disconnected>
That is very simplified (although it used to be that simple and I would do that kind of thing by hand occasionally):
- almost nobody uses Port 25 anymore on the Internet as it is unencrypted,
- there is often an authentication protocol for untrusted client hosts so any server cannot be used for spam
- That is why a private server may be necessary
There are conventions for inserting binary (i.e. non-ASCII) attachments and such, but typically a PLC would not get to that level.
