Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Ok, I'm a bit confused with these mail protocols so I just have to ask.
I'm making an app for a very special use case we have at work. We have two e-mail servers sending mail to eachother (two seperate domains). The problem is that one of the servers is frequently moved (the server is in the field, and has to be mobile). When that server is moved, it can't be connected to our network and therefore mail cannot be sendt to this server.
What I'm making is an app that will be between our two e-mail servers, intercepting the e-mail trafic that goes between them and, if one of the servers cannot be reached, my app should store the e-mails in a buffer, so that when it detects that the e-mail server is back online, it can safely send the e-mails the other server did not recieve due to it being offline. The e-mails in the buffer should also be able to be sendt to an alternative e-mail so they can be acted upon immidietly should the recieving e-mail server be down for longer than normal...
So, I've figured out that I need to use the SMTP-protocoll to send e-mail, but what do I use to recieve them? All examples I've read so far in C# and Python are about connecting to an allready established POP3/Imap4 server and recieve mail from there, and I think setting up my own POP3/IMAP4 server for intercepting mail before sending it on is doing it the really hard way...
So how do i recieve/intercept e-mail without the use of POP3/IMAP4?
If I understand the question correctly you simply want to buffer your emails. You could be much better off either using a third party to act as a backup mail server or set up additional mail servers as lower priority servers to collect the mail should one of the servers not be reached. You can ask on ServerFault about setting something like this up. I can't see the real benefit of writing an app yourself.
If you do wish to write something yourself then you will most likely wish to write both an SMTP server and and SMTP client one to accept the emails and one to deliver the message.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I have some problem.
I have client and server. Client connect with server over TCP.
Then, client send some data (separated by chunks), I don't know what is the length of data (TLS handshake). But I know that client send some data with fixed length, and then stop, until not received some response, then he send data with fixed length again.
I need read all chunks, until client stopped send (because so many chunks). How to do that ?
I have only one idea, it's timeout. Read data in loop and set timeout between iterate. If timeout is ended, then data complete collected.
Perhaps there is a more elegant solution?
Based on the information in your comments, you're doing this wrong. The correct way to write an HTTPS proxy is to read the CONNECT line, make the upstream connection, send the appropriate response back o the client, and then if successful start copying bytes in both directions simultaneously. You're not in the least concerned with packets or read sizes, and you should certainly not make any attempt to 'collect' packets before retransmission, as that will just add latency to the system.
You can accomplish this either by starting two threads per connection, one in each direction, or via non-blocking sockets and select()/poll()/epoll(), or whatever that looks like in Go.
BUT I have no idea why you're doing this at all. There are plenty of open-source HTTP proxies already in existence, and as you're dealing with HTTPS there is no value you can possibly add to them. Your claim about 'business logic' is meaningless, or at least unimplementable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
My server needs to send emails on the behalf of my client, and the client wants this email to at least appear to originate from them.
The easy way is to just spoof the From address. The hard way is to get the client's username and password, and actually send from that account.
My questions are:
Will spoofed email trigger spam filters? (In my test, Apple Mail did not think it was spam.)
Is this considered a bad practice, or unethical, or in any way frowned upon?
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day). We are not sending out spam at all.
Because this is an important client, I don't want to do anything that would reflect negatively on them (or myself).
Thanks. Hope this isn't too subjective.
Email spoofing is not completely preventable, since the basic protocols from email exchange don't verify anything.
This might help you decide:
http://en.wikipedia.org/wiki/Email_spoofing
Which says historically:
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, these sorts of "legitimate" uses fell out of favor.
I would think it is acceptable as long as the message is spoofed to a return address you would like people to respond to.
However, it would be more standard and appropriate to use email/pass.
I suppose it depends on how difficult this would be in your situation, but if reasonably able, don't spoof.
You said:
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day).
If the email contents have perhaps a small footnote, I don't think it would be terrible. I have seen similar things from many companies. It's your decision.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am interested to know the technical background of how this services can determine if my email reached the inbox or not(as this is the key servicethis providers offer). If I send an email to somebody wh uses Yahoo messenger or Gmail or maybe just an enterprise email address, what does the ISP have to do with that? Isn't the email filtered after it reached the Yahoo or Enterprise server, and than moved to Inbox or Junk or whatever other folder?
(full disclosure: I currently work for SendGrid as a web developer, so I have some insight but maybe not the low-level technical answers you're seeking)
From a slightly simplistic view, when we go through the SMTP process of delivering a message to an ISP/ESP, we generally know that the message has been "delivered" and we track it as such in your statistics. We also set up feedback loops (FBL's) with ISP's/ESP's which can ping back to us if a user flags a message as spam, which we then subtract from the "delivered" total.
How they route the message and make the decision to move it an Inbox or Junk folder is based on whatever criteria they have, and as far as I know, there is no FBL that can be set up to alert us to that fact.
We do, however, work very hard with our customers to teach them how to "warm up" an IP address for sending good, non-spammy messages, which builds up a "reputation" for an IP address (search google for "sender score"). Obviously the closer to 100% the better. We also have automated systems in place which may alert us if outgoing messages seem "spammy" and we'll put them on hold and alert you so you can make corrections. After all, our reputation is also on the line.
Hope that helps a little.
Well, if I recall correctly, SendGrid uses embedded images in the email and tracks if the image gets loaded as a way to determine if the target user read the email. This, of course, is fairly unreliable.
I certainly never allow my email client to automatically show images by default, so the image won't be requested and SendGrid won't be able to count this email as opened.
See these links for more details... now comes the RTFM! :)
http://docs.sendgrid.com/documentation/apps/click-tracking/
http://en.wikipedia.org/wiki/Email_tracking
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This question got me thinking, and I now realize that I don't know anything about the internals of MTAs.
What exactly does an MTA do? Everything after the SMTP protocol seems like dark magic to me. Let's say that I wanted to code a minimalistic MTA (or MDA) just for sending emails, what would I need to learn/do?
Edit: I don't actually plan on writing an MTA, I just want to understand how it works internally.
--- edit after somehow noticing you talked about possibly writing a MTA ---
To write a MTA, you need to open a server socket. When someone connects, you need to send and receive text (ascii) data on that socket in compliance with the SMTP protocol. SMTP is very chatty, so you can expect a few rounds of communication.
The initial round of communication typically tells you whether SMTP is supported or ESMTP is supported. The second (optional) round of communication is to determine security / encryption / feature support. Eventually the "client" side will ask to send a message to a particular address / set of addresses. When done, the server will indicate that it's ready to get the body of the email message. When the body of the message (and it's optinal attachments) have all been transmitted, the MTA will tell you it received the message fine. At that point in time, the MTA will act as a client to other MTAs discovered via DNS MX records to get your email closer to it's destination MTA which will copy it into someone's inbox.
So an MTA is needed because mail delivery on the client side is the equivalent to handing a physical letter to a post office. Post offices are responsible for inter-postoffice routing (which parallels to MTA-to-MTA transmission). The destination Post office is then responsible for delivery of the letter to the post office box or home address (which parallels one's computer inbox).
They don't call it e-mail for nothing.
--- original post follows ---
A MTA will accept a mail message, see if it can forward or deliver it, respond if it can be forwarded or delivered, and then forward or deliver it if it indicated it could.
How the message gets closer to it's final destination usually has a bit to do with DNS. MX (mail exchange) records in DNS indicate servers which are responsible (or at least closer to the responsible server) for particular email domain names. It is not possible to fully understand how a mail message gets closer to it's destination without understanding how DNS works.
A MTA typically looks at the delivery address, and either is configured to be the "end point" of the email address's mail domain, or knows that server XYZ is one hop closer to the email address's mail domain. If it's an endpoint, it will copy the message from the wire into someone's inbox. If it's relaying it will "forward" the message to the next MTA.
Here ya go: http://en.wikipedia.org/wiki/Message_transfer_agent
Quickly, the MTA receives the raw message, decides where it's ultimate destination is, and then forwards the message on to that destination.
A very simple MTA can be written the delivers only to local inboxes. The MTA is an "easier" part of the system to write because you can behave badly but still be functional, so your interoperability with other systems is less of an issue (that's where much of the complexities of email lie nowadays, that and spam/virus checking).
The real contract of an MTA is simply that if you accept the message from the system sending it to you, you accept responsibility to deliver that message. Thus, when that socket closes with an acknowledgement of acceptance, the delivering systems job is done and it's all in your hands.
If you happen to do a crummy job, mail is lost, and it's your problem. But it's still fun to play around with.
Edit: The original tutorial I linked to has gone 404. Here's another that's ok: https://troubleshootguru.wordpress.com/2014/07/06/mail-server-components-mta-mda-mua/
In short, a MUA is a user client that uses SMTP to send an email to an MTA. The MTA is a server that is responsible for routing the MTA to its destination. If that destination is another server, the MTA hands the email to an MDA. The MDA is a client on the server that uses SMTP to forward the email to the other server, which is also an MTA.
So what do you need to learn? If you want to write an MUA or MDA, you need to learn how to open a socket to another computer, send SMTP commands, and receive SMTP responses. If you want to write an MTA, you need to learn how to listen for socket connections on a port, receive SMTP commands, and send SMTP responses.
If you like Java, try the code on this page as a starting point for a client.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 4 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
My VPS provider (Slicehost) doesn't provide an SMTP server. I use Google Apps to send and receive mail for my domains, but I want to be able to programmatically send e-mail.
I've been Googling this issue on and off for many months, and I just can't seem to get a clear picture of what I need to do. Do I just need an MTA like postfix? Do I configure it as a "satellite", or an "internet" site? Do I need to make any DNS changes? If I want to programmatically receive e-mail someday, are there any configuration options I should be careful about tinkering with? Also, if my VPS host did provide an SMTP server, what wouldn't I need to do, that I'm doing now?
Thank you!
Edit: A quick synopsis of my findings:
Update /etc/hosts and /etc/hostname to reflect the FQDN (for example, mail.domain.com or sub.domain.com instead of slicename)
Reboot and verify with hostname -f
Set up reverse DNS (which is owned by whoever owns the IP pool) to point at the same FQDN
Check that the RDNS has propogated with dig -x server.ip.address
sudo aptitude install postfix telnet mailx
Use internet site setting
Set FQDN to whatever was chosen above
Test with mail whateveryouremailis#gmail.com
Have you looked here, seems to me that there is plenty of information to get started. I found mail-server-slice-setup to be quite informative.
To my experience, when email providers check for spams, they check 5 main things other than content:
(When I say domain, I'm referring to the domain of the sender's email address.)
"A" record (IP) of the domain name exists
MX records of the domain name exist
PTR record (Reverse lookup) of the sender's IP address exists (Sometimes, I think it is also checked to see if the PTR record has the same A record as the original domain)
SPF record of that domain matches the IP number (This is a list of IP numbers allowed to send emails of that domain. Although this would be a great solution for spam filtering, this is not an official record, so it is not always checked. Check out the SPF setup wizard.)
The IP segment of the server is not a blacklisted segment.
The fifth one is the one that was a problem for me. Apparently email providers such as Hotmail, Gmail, Yahoo drop all incoming email from widely used server providers such as Amazon EC2. In that case, there's simply no way to guarantee the delivery of all outgoing emails, so you would have to relay all outgoing email from some other SMTP server outside the blacklisted segment. The easiest way to do this is configuring Postfix (or whatever MTA you're using) to automatically relay all emails. You can find plenty of articles on this if you do some googling.
If that is not the case, then all you need is a simple MTA like Postfix, as long as all the necessary DNS records listed above are configured properly, you should have no trouble sending emails.
Other answers have provided information about the mechanics of sending email, but one thing you need to consider is what sender address you're going to use, and how you're going to deal with bounce messages.
Let's say you're sending emails from sender#example.com; then (as Murat Ayfer noted) you need to make sure that your host is allowed to send mail according to example.com's SPF record. (This may or may not be configured by IP address -- see the SPF site for more details.) If you're in charge of the example.com domain, then this shouldn't be a problem. Being listed as an acceptable sender for the domain is an important step towards your emails getting through.
The next thing you need to worry about is how to deal with bounced emails. If some other host receives emails for example.com (i.e. the MX record points elsewhere), then it's mainly someone else's problem. (Note however that your application has to be prepared for a failure during the SMTP session to the mailserver on your host, due to syntactically invalid email addresses, for example.) But if you decide that you'll receive mail for example.com on your host, then you need to worry about dealing with retry messages, bounce messages, double bounce messages, and a whole lot of other general mail server administration. There's some info on handling undelivered emails in web applications which might be helpful, but I also suggest getting a good book on Postfix or whatever mail server you decide to use.
Just install something like postfix as "internet site" and you'll be able to send mails directly from your VPS
it should work with default settings but it would be recommended to also read a few docs/how-to's to secure it properly