I'm writing a C project that needs to validate the emails before they are stored. I will have to cross compile, so using regex.h is not an option.
Is there a surefire way to validate an email by checking if it is a deliverable address without actually having to send an email in C?
Alternatives or suggestions are welcome if there is no way of doing this.
You can perform a DNS query of the domain name (the part of the e-mail-address after the # symbol) to determine whether the domain is valid and has an MX record. To verify the username (the part of the e-mail-address before the # symbol), you will have to query the destination mail server itself, for example using the VRFY SMTP command. However, for security reasons, some mail servers may not support this command.
The C language itself does not provide any functions with which you can send network packets. However, most platforms provide an API which offers this functionality (e.g. POSIX sockets, Windows sockets). Some platforms also provide an API which performs the DNS query for you. Also, several libraries exist which provide this functionality.
There is no such procedure in any language.
Related
I want to write a client and server in C preferably, simple C++ if necessary.
The server will run on some flavor of Linux, the client is for testing the server.
I want to ensure messages are received and error free; therefore I will use TCP.
I want them to communicate securely; thus I will use the latest version of TLS (v1.3).
I intend to use the GnuTLS library for reasons:
Actively updated by reputable open source project
License permits selling product
Given the above, if implemented and tested, I could claim that the client/server communication is secure, reliable (a.k.a. assured), and error-checked. Yes?
Am I missing something? Is anything patently false?
Edit: certificates... i think i'm missing something about certificates to protect against man in the middle attacks...
TLS is a complex topic. Depending on your specific code the TLS connection might succeed even if you fail to properly validate the certificate. Thus, just based on what you state so far in your question it cannot be assured that the data are transferred with proper end-to-end protection and that no man in the middle can manipulate the data.
This may not be in the right location, so tell me and I'll move it.
I am a recent EE grad and I was hired to build a system that exists on a SoC with a simple 32-bit processor. The system basically monitors several external devices and performs some DSP on it, and then is supposed to send the results using a WiFi device (in my case I have the ESP8266 using UDP) to an email server for logging/notification.
I have been trying to find a library that I can use, but my uC can only program in C and I have it set up for UDP, and everything is in C++ using some other protocol, or something else completely.
I am great at DSP, decent at SoC's and uC's, but when it come to this email server communication thing I am at a loss.
I have successfully configured everything for the sensors, the datapath, the DSP, and connected the system to my WiFi via UDP, but I have yet to figure out how to send data to any servers.
Could someone help me understand how I should go about this?
I have looked into some simple SMTP commands such as HELO, MAIL, RCPT, DATA, etc. but I cannot understand how I actually should implement them in my code.
When I send out the WiFi data via UDP what type of data do I send and how do I format it? Do I need to send any other kind of flags? How should I expect the response? I also know the data has to be transformed into base 64 which is confusing me further.
I am also not super familiar with UDP to begin with, I have been using libraries that are part of the SoC's default library to connect to my WiFi.
I know these may either seem like obvious or stupid questions but it is were I no longer have any knowledge, and everything I find online doesn't make sense, or doesn't attempt to explain it, just gives a pre-made solution
I have found the RFC2821 but it doesn't get any clearer.
I know that's a lot but any help at all would be a lifesaver!
Since you are asking this question, I'm assuming that you are not booting and running an OS suitable for micro-controllers such as an embedded variant of Linux or such. If you were, you would simply be able to take advantage of possibly built in applications or other existing code.
But you don't mention having written an Ethernet stack, so are you using some other library or operating environment which might have some of the functionality needed for an implementation of SMTP?
If you don't and really do need to write your own SMTP client to run directly on the processor you are using, then you should be able to find plenty of examples of source code for this. A quick google search of How To Write an SMTP client showed a few articles with some example code. One article seems to be an exact hit, but you need to look at it further.
However, I would highly suggest just sitting down with a telnet client and connect to an SMTP server you are allowed to use and try the commands you need to just send a message. If you only need to send text, you don't need to get involved in MIME encoding or anything like that.
Which way is standard to generate IETF-syslog messages in the C language?
There is the header <syslog.h>. But it provide no options to use the STRUCTURED-DATA mechanism (rfc-5424).
Of course, messages could be constructed by hand directly to a socket. But it seems that such way is not standard.
Is there another standard way?
The standard way to do this is to have your application log messages using the normal openlog(), syslog() and closelog() routines from <syslog.h>.
That will send the messages to the syslogd running on the local machine. If the messages are then to be forwarded over the network using the syslog protocol, syslogd itself will take care of this. For example, this might be done using a target like #hostname in the syslogd.conf file.
In short, your application is expected to log messages to the syslogd, and syslogd decides where to send them (including over the network). This allows the local administrator maximum control.
Hmmm... that RFC is less than 2 years old. I don't think it is a big surprise to see that the ususal suspects haven't implemented it yet.
Most of the applications I've seen that use TCP, do roughly the following to connect to remote host:
get the hostname (or address) from the configuration/user input (textual)
either resolve the hostname into address and add the port, or use getaddrinfo()
from the above fill in the sockaddr_* structure with one of the remote addresses
use the connect() to get the socket connected to the remote host.
if fails, possibly go to (3) and retry - or just complain about the error
(2) is blocking in the stock library implementation, and the (4) seems to be most frequently non-blocking, which seems to give a room for a lot of somewhat similar yet different code that serves the purpose to asynchronously connect to a remote host by its hostname.
So the question: what are the good reasons not to have the additional single call like following:
int sockfd = connect_by_name(const char *hostname, const char *servicename)
?
I can come up with three:
historic: because that's what the API is
provide for custom per-application policy mechanism for address selection/connection retry: this seems a bit superficial, since for the common case ("get me a tube to talk to remote host") the underlying OS should know better
provide the visual feedback to the user about the exact step involved ("name resolution" vs "connection attempt"): this seems rather important, lookup+connection attempt may take time
Only the last of them seems to be compelling enough to rewrite the resolve/connect code for every client app (as opposed to at least having and using a widely used library that would implement the connect_by_name() semantics in addition to the existing sockets API), so surely there should be some more reasons that I am missing ?
(one of the reasons behind the question is that this kind of API would appear to help the portability to IPv6, as well as possibly to other stream transport protocols significantly)
Or, maybe such a library exists and my google-fu failed me ?
(edited: corrected the definition to look like it was meant to look, thanks LnxPrgr3)
Implementing such an API with non-blocking characteristics within the constraints of the standard library (which, crucially, isn't supposed to start its own threads or processes to work asynchronously) would be problematic.
Both the name lookup and connecting part of the process require waiting for a remote response. If either of these are not to block, then that requires a way of doing asychronous work and signalling the change in state of the socket to the calling application. connect is able to do this, because the work of the connect call is done in the kernel, and the kernel can mark the socket as readable when the connect is done. However, name lookup is not able to do this, because the work of a name lookup is done in userspace - and without starting a new thread (which is verboten in the standard library), giving that name lookup code a way to be woken up to continue work is a difficult problem.
You could do it by having your proposed call return two file descriptors - one for the socket itself, and another that you are told "Do nothing with this file descriptor except to check regularly if it is readable. If this file descriptor becomes readable, call cbn_do_some_more_work(fd)". That is clearly a fairly uninspiring API!
The usual UNIX approach is to provide a set of simple, flexible tools, working on a small set of object types, that can be combined in order to produce complex effects. That applies to the programming API as much as it does to the standard shell tools.
Because you can build higher level APIs such as the one you propose on top of the native low level APIs.
The socket API is not just for TCP, but can also be used for other protocols that may have different end point conventions (i.e. the Unix-local protocol where you have a name only and no service). Or consider DNS which uses sockets to implement itself. How does the DNS code connect to the server if the connection code relies on DNS?
If you would like a higher level abstraction, one library to check out is ACE.
There are several questions in your question. For instance, why not
standardizing an API with such connect_by_name? That would certainly
be a good idea. It would not fit every purpose (see the DNS example
from R Samuel Klatchko) but for the typical network program, it would
be OK. A paper exploring such APIs is "Simplifying Internet Applications Development
With A Name-Oriented Sockets Interface" by Christian Vogt. Note
that another difficulty for such an API would be "callback"
applications, for instance a SIP client asking to be called back: the
application has no easy way to know its own name and therefore often
prefer to be called back by address, despite the problems it make, for
instance with NAT.
Now, another question is "Is it possible to build such
connect_by_name subroutine today?" Partly yes (with the caveats
mentioned by caf) but, if written in userspace, in an ordinary
library, it would not be completely "name-oriented" since the Unix
kernel still manages the connections using IP addresses. For instance,
I would expect a "real" connect_by_name routine to be able to
survive renumbering (for instance because a mobile host renumbered),
which is quite difficult to do in userspace.
Finally, yes, it already exists a lot of libraries with similar
semantics. For a HTTP client (the most common case for a program whose
network abilities are not the main feature, for instance a XML
processor), you have Neon and libcURL. With libcURL, you can
simply write things like:
#define URL "http://www.velib.paris.fr/service/stationdetails/42"
...
curl_easy_setopt(curl, CURLOPT_URL, URL);
result = curl_easy_perform(curl);
which is even higher-layer than connect_by_name since it uses an
URL, not a domain name.
I need to decode a packet sent using TIBCO-RV and pull fields out of the header and skip over the message body. I have not been able to any examples or documentation. Does anybody know of any open source applications that might do this or if there is a Wireshark dissector out there somewhere?
Maybe you should try applying for a license and getting the official documentation. According to Wikipedia:
TIBCO provides messaging APIs in C,
C++, Java, Visual BASIC , Perl and
.NET to receive data feeds on MS Excel
spreadsheets and other applications of
choice.
Failing that, you could perhaps dive into the TIBCO:RV Perl module.
The methods which TibcoRV implements reliable mutli-cast are propriety, but one would assume easy to reverse engineer. I don't believe any of the official documentation goes into detail on the packet level detail. It's quite easy to get the data out if you have the API.
Several things come to mind:
Is the client on your machine running? This is required in order to create the multicast subscription (unless you are using broadcast mode). Otherwise, you need to have some client subscribe to the multicast channel, or your switch shouldn't forward the traffic.
Generally, you will have a single rrd running locally. You have TCP traffic between the RRD and your app. You can use an app like socketsniff to view the traffic between the two.