Is SMTP protocol only for sending? - smtp

Is it possible to use SMTP as described in RFC 5321 to receive mail or is it prohibited by this spec?

SMTP is used only for sending mail - transferring mail to mail servers, and between mail servers. POP and IMAP are two popular protocols (but not the only protocols) for mail user agents (end-user email clients) to retrieve mail, which I'm guessing is what you're asking about.
To put it a different way, an SMTP conversation is initiated by software that wishes to transmit email to another device. It's not usually used as the last-hop step to deliver email to a user - those conversations are usually initiated by software that wishes to receive the email.

ESMTP extensions for email receiving
SMTP is used to receive email servers listed in MX recerds from "all internet".
If you want to use it to receive your email from relay accepting emails from "all internet":
with static IP address but without permanent internet connection you may use ETRN command [RFC-1985]
https://en.wikipedia.org/wiki/ETRN#ETRN
with dynamic IP address you may use ATRN [RFC-2625]
https://en.wikipedia.org/wiki/On-Demand_Mail_Relay
Both extensions are designed for "for domain emails" not for "single mailbox emails".

Related

Setting up mail smtp relay service to send and receive mail

I have very limited knowledge about SMTP and IMAP/POP. SMTP --> sending message, IMAP--> Mainly for receiving messages.
I have a woocommerce website and i already did setup my email system to use SMTP relay using zoho. I believe zoho also provide mailbox services since I am able to communicate with my customer(both two and fro) using its email service. They have their app and i can receive and send mail from that app. Obviously, I have set up all the records including MX to send/receive the email to my zoho inbox.
No i want to move my email services to postmark or like sendinblue. All i can see the setting related to sending the mail but how/where will I receive the mail when user reply on that??
On the postmark website it says:
Since Postmark is not a mailbox provider there's not the ability to generate mailboxes for receiving email using IMAP or POP3.
Question 1) Does the SMTP relay server is actually a different physical machine from IMAP server for sending/receiving messages. I guess both are different but why are these companies not providing solutions like zoho. Pardon me if I did not understand the use case.
Question 2) What to do in this case ???. My case is simple. I send notifications to customers regarding their orders. If they want they can reply or enquire. I receive the email on my phone and I can reply on the same mail-chain like we have on Gmail.
Question 3)
Do i need to buy some another service along with these to receive and reply back on the email ??? Like from godaddy or somewhere else.

DMARC Anti-Spoofing Error When Sending Email with Sender Yahoo Domain Other Than Server Domain

I am using our email server at [mydomainhere].com to send emails through a web site UI. I just used the UI to send an email from [myemail]#yahoo.com. And received an Undeliverable message at my yahoo email address.
mta1400.mail.ne1.yahoo.com rejected your message to the following e-mail addresses:
[myemail]#yahoo.com
mta1400.mail.ne1.yahoo.com gave this error:
Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html
More information can be found here:
http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-breaks-mailing-lists.html
Any help would be appreciated.
Yes Allan, you are correct in assuming that the anti-spoofing that Yahoo (and now AOL) have turned on is permanent. The technology they are using is called DMARC. Yahoo has published a DMARC record in their DNS:
$ dig TXT _dmarc.yahoo.com. +short
"v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-rua#yahoo-inc.com, mailto:dmarc_y_rua#yahoo.com;"
Every mail server that supports DMARC will look up that record in Yahoo's DNS and apply Yahoo's p=reject policy. In effect, what Yahoo has done is stated to the world, "if the email does not originate from this list of IPs (SPF) or bear this crytographic signature (DKIM), then reject (p=reject) it." Since your mail server is not in their list of mail servers IPs nor are the messages signed with Yahoo's DKIM key, a substantial and growing portion of the mail servers on the internet are going to reject it or deliver it to the Spam folder (Gmail).
In addition to the SPF & DKIM checks, DMARC also introduces the concept of alignment. In addition to passing SPF checks (which apply to the Envelope Sender), DMARC requires that the domain in the messages 'From' header passes SPF. This prevents you (and bad actors) from sending messages with a header From domain of Yahoo.com and an Envelope Sender domain of attacker.com, which the recipient will never see. This alignment also extends to the DKIM signature, requiring not just that the message is signed with DKIM, but also that the dkim signature domain (d= property) matches the From header domain.
we will just have to prevent users from using their yahoo email address in the sender email field
Coding in a check for the yahoo.com domain is a hack that won't last long. AOL has already joined the thousands of domain owners with DMARC p=reject policies. They won't be the last of the Very Large Email providers to publish p=reject DMARC policies. A much safer approach is to evaluate SPF against your mail servers public IP and the domain in the users selected email address. If the SPF check fails, then choose an option:
Inform the user that their choice of domains doesn't permit 3rd party senders and they should choose another.
Alter the From header to send from a domain you control:
From: "user#yahoo.com via" <my-app#my-domain.com>
As already stated, you could define Reply-To if you wish for replies to expose the senders real email address.
Set up local usernames that forward to the sender's real email address. If you've used Craigslist, you're familiar with the idea. You maintain a mapping of local addresses and the email address they forward to.
Based on what you've said about your web application, it seems like #2 is the best fit.
I have had a similar problem with mailing lists that I maintain (e-mails with a From address something#yahoo.com bounced). I solved my problem by changing the From, Reply-to and Errors-to fields of the e-mails' headers as follows:
From: Organization name <no-reply#somedomain.org>
Reply-to: my-email-address#yahoo.com
Errors-to: my-email-address#yahoo.com
I suspect that similar changes will fix your problem.

What further happens after emails are received on SMTP ? Who Stores the email, is that SMTP?

I am developing a customized SMTP server, it is almost complete too. Other SMTP can now contact with my SMTP and I can successfully recive what they send to me. But now I am thinking is it responsibility of SMTP to store the received email OR I will have to pass recived values to any other program that stores these values(such as to,from,data) of recived emails. If so then what is that program ? If not then who will store received values, is that SMTP ??
What you've written is a Mail Transfer Agent (MTA). A piece of software that delivers mail to a user's mailbox is called a Mail Delivery Agent (MDA). The MDA can be a part of the MTA (that is, you can write code in your server that knows how to deliver to mbox, maildir, etc., as for instance Sendmail does), or it can be a separate program like procmail or maildrop.
If you would like to model your custom SMTP server after Postfix (which happens to be the only SMTP server I have experience with), Postfix implements the storing of emails in text files using Postfix-maildrop in the mbox format located at /var/mail/[username] (in the Ubuntu/Debian universe, this is where they live anyway).
I found more details in another thread listed below:
https://unix.stackexchange.com/questions/23277/where-does-postfix-store-email
Mbox format described:
http://en.wikipedia.org/wiki/Mbox
https://www.rfc-editor.org/rfc/rfc4155

How does a mail relayer doesn't send a mail to already received recipients?

i was wondering.
Suppose i have an exchange server, (the domain can be me#company.com),
also, i have a relay server, that accepts requests to internet domains (gmail/yahoo/etc).
suppose i send a mail to: (you#company.com; him#gmail.com) - from a user in the domain (me#company.com)
The mail is sent to the exchange server, then the exchange groups the domains (company.com and gmail.com) => it puts the mail into you#company.com mailbox.
then, the exchange sees that it needs to send into him#gmail.com, so it will send it to the relay server.
the relay server will get the SMTP request:
from: me#company.com
to: you#company.com; him#gmail.com
the question is - how does the smtp relay server knows not to send it to you#company.com - thus causing duplicate mails received?
also, how does the gmail server knows not to try to send the mails it receives again? (because they only get smtp requests, similar to a client that sends the mail)
thanks in advanced!
The content of the mail is not parsed by either exchange or the relay for determining where the mail should go. Everyone in this context is talking SMTP with one another, and specify recipients with the RCPT protocol message. So your mail client tells exchange two RCPT, exchange decides one of them is remote, then says one RCPT to the relay, and so on and so forth. This document specifies the SMTP protocol where you may read about the RCPT verb.
The headers you see are not used to deliver the message. Instead, SMTP defines a concept called envelope which has a completely different set of headers. As a common illustration, this is how Bcc: works, too; the recipient address is copied to the envelope, then removed from the message which goes inside the envelope.
When a message is delivered, the envelope sender is usually copied into the Return-Path: header, and you can sometimes see the envelope recipient information copied into the Received: headers.
At the point where a mail server decides to which destinations a message should go, there is commonly one copy of the message (spool file, queue entry, what have you) for each distinct destination. So if you send to from you#company to me#company, you#private, and friend#gmail, the first server might determine that the external addresses should both go to the same outbound relay, while the internal copy is delivered locally. Then the relay similarly decides that it needs to contact two distinct destination, so the single incoming message gets copied to two outbound messages, one to you#private and the other to friend#gmail.

Preventing Recipients from getting an email. - How Email Processing Works?

When you send an email with this:
From: Jeff#yahoo.com
To: XXX#aol.com, XXX#aol.com, XXX#aol.com
CC: james#gmail.com
Which Mail Server sends the message via email to the recipients in the TO & CC field? Is it the SMTP server or the server owned by the recipient (like aol.com)?
When you write an email and send it, you will hand it off to some SMTP server you have access to. That server will then contact the recipients server (or intermediate server) and deliver the email to that SMTP server. The SMTP server on the receiving end will somehow, depending on their setup, deliver the email to their users.
In your example, you will properly give yahoo.com's SMTP server the email. Then that server will contact aol.com and deliver the email there. It will also contact gmail.com and deliver the email to their SMTP server.
You should read this part of the SMTP rfc which have a very good explanation about the process.
How you will go about preventing that an email is delivered, is to somehow control one of the SMTP servers that is contacted in the process - or not send the email at all. When you see the email delivered in your own mailbox, it is properly way to late trying to prevent the other recipients receiving the email.