I am doing a Networks course and as I was reading about SMTP I thought about the following matter:
If a user sends an email to user1#example.com, user2#example.com, user3#example.com, does it take the same amount of time to send the emails separately as it does to send it as a multi-recipient email?
Or when the first one is sent, the next two are easier to send since the connection is already established with that server? Or does the connection close immediately thus making no difference?
What about when the emails belong to different domains?
It depends on how the MTA is programmed. The SMTP protocol allows the sender to send multiple RCPT TO commands, to list all the recipients of a message, and any reasonably-designed MTA will make use of this to consolodate them.
For the multiple-domain case, your mail client will use a single connection to upload the message to its submission server. That server will then use one connection per destination domain for the recipients.
Related
I'll like to process incoming email on a specific email. In aws docs it says
Although you are not required to publish an MX record to receive mail through Amazon SES, if you don't publish the record, Amazon SES will receive mail for your domain only if you explicitly route it to Amazon SES.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-mx-record.html
How do I explicitly route email to SES?
After hours of research and failed attempts of having SES receive emails without the use of a MX record (had set up an additional Route via gSuite / Google Apps), here is my best suggestion on how to go about this.
Short Version
Create a subdomain and point its MX record to SES after inserting the TXT verification record. After creating the necessary ruleset to receive and save email from any#sub.domain.com, you can now have SES receive email from any email address you own (even if it's not verified with SES) by simply forwarding its emails to the SES enabled subdomain email address.
Long Version
Unfortunately, it does still require an MX record, but check it out...
You can create a custom subdomain on your primary domain and call it anything. In my case, I called it ses.mydomain.com
Next, I added my newly created subdomain to SES via the Domains link.
Immediately upon adding it as a domain to SES, a pop-up window appears displaying the required TXT verification record and MX mail record.
Shortly after assigning these two DNS records to my subdomain, the subdomain is verified and able to receive email after setting a few quick rules via Rule Sets!
Here's the cool part - you can still have SES receive email from any email address you have access to.
How you might ask?
By just setting up a forwarder on the email address you do want to send to SES, by forwarding it to the SES-enabled subdomain email address.
Meaning - If SES is able to receive email from someone#ses.example.com, but you want it to actually receive email from someone-else#example.com, then all you need to do is forward someone-else#example.com to someone#ses.example.com!
Remember, you still need to create the necessary rules to receive emails. See this AWS Blog Post for more information.
Use one of the AWS SES's inbound endpoints:
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/regions.html#region-select
e.g. for US-EAST-1 the inbound endpoint is inbound-smtp.us-east-1.amazonaws.com. For receiving only you do not use SMTP endpoints. The procedure is pretty much the same using MX records or not: somewhere (in your DNS or in your mail handling system) you must point to a SES inbound endpoint.
For example, my MX records point to Google Apps, but using 'Hosts' and 'Routing' (inside Google Apps/Gmail options) I managed to relay only one recipient to SES. So every e-mail my domain receives goes to Gmail recipients as usual, except for one special_recipient#mydomain.com which I relayed to SES (which, in turn, goes to SNS then to SQS).
from:
https://aws.amazon.com/blogs/aws/new-receive-and-process-incoming-email-with-amazon-ses/
Now you need to route your incoming email to SES for processing. You have two options here. You can set the domain’s MX (Mail Exchange) record to point to the SES SMTP endpoint in the region where you want to process incoming email. Or, you can configure your existing mail handling system to forward mail to the endpoint.
I am thinking about implementing my own SMTP server that can receive mail and store it. As this is a small hobby project, I'd prefer to keep the code simple – so, for example, I don't want to implement logic for sending mail. However, the following section from RFC 5321 makes me worry:
The server must give special treatment to cases in which the
processing following the end of mail data indication is only
partially successful. This could happen if, after accepting several
recipients and the mail data, the SMTP server finds that the mail
data could be successfully delivered to some, but not all, of the
recipients. In such cases, the response to the DATA command MUST be
an OK reply. However, the SMTP server MUST compose and send an
"undeliverable mail" notification message to the originator of the
message.
Does this mean that, even if I normally only return 250 OK when I'm sure the message has been stored safely, I am forced to implement stuff for sending failure notices just in case someone decides to send a mail to both an existing and a non-existing mail address at the same time? Is there any way to get around it without violating the standard? If there isn't, how bad would it be to just send back 452 Too many recipients (my RCPT limit is 1, not 100 as required by RFC 5321) whenever someone tries to send a mail to multiple recipients?
In such cases, the response to the DATA command MUST be an OK reply.
However, the SMTP server MUST compose and send an "undeliverable mail"
notification message to the originator of the message.
That seems rather unambiguous to me. If you are to be standards-compliant, you MUST both return an OK response (because the message could be delivered to some recipients) and send failure notification to the originator (because it could not be delivered to other recipients).
On the other hand, your question also mentioned that you will only accept delivery for a single recipient, so a) you've already resigned yourself to not being standards-compliant anyhow by not allowing 100 recipients and b) the failure mode of "mail data could be successfully delivered to some, but not all, of the recipients" will not be possible if there can only be a single recipient.
After re-thinking the situation, I think that it's actually possible to do this in an RFC-compliant way if the server can assure that the mail can be delivered to all recipients at RCPT command time – after all, individual recipients can be rejected when the corresponding RCPT command was received. Of course, this means that the server e.g. has to ensure that enough harddisk space is available for each recipient and the maximum mail size. And a server could just deny mail to a recipient if his current mailbox size plus the maximum mail size is more than the maximum mailbox size.
Of course, the actual implementation is a bit more complicated in order to support concurrency.
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
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.
Is it possible to retrieve the SMTP response of a mail. For example, I am sending a mail to non existing email id. Surely our server will send us a mailer daemon failure mail to our mail id. I need to capture that failure mail.
How its possible? please explain me. Some time we may enter more than one non existing email id, so i have to retrieve all the failure mail alone for every corresponding emails
Please guide me!
Thanks in advance,
Praveen J
I think I understood your question correctly now. As I understand, you are writing an application to send mail. And in your application, whenever you send a mail, you also want verify that if mail was delivered and also if it was not delivered then you want to get hold of the failure message in your application. Is that how you mean?
Well, if that is how you mean, then I think it is impossible to track the mail status with your apllication code. For instance if you are using java sendMail in your apllication you can only ensure that the send happened from your code successfully(without any send exceptions like java.net.SocketException or javax.mail.MessagingException). But, you can never ensure if the mail really reached the recepient. i.e. you can never track in your application if the mail was rejected due to wrong recepient address or any other error like illegal attachment at receipient mail server or errors like blocked sender id etc.
That is because any such error condition will be communicated by the receipient mail server to the sending mail server the information of which is present in the sent mail's header.
Does that answer your question? (Or did I understand your question correctly? ;-))
I am not sure if I am getting your question right. If you send an email to any non existent address say xxx#gmail.com from your address yyy#yourhost.com, the mail server at gmail.com replies to the mail server at yourhost.com with failure message and reason, with your delivery address and you receive the fialure mail automatically. you don't have to do anything extra in this.
If you are talking about seeing mail headers, then it depends on which client you are using. For instace, if you are using MS outlook, you can right-click on the message and click options and then see internet headers section to get mail headers. If you are using some web based mail then i am sure there will some option to view detailed mail headers.
The bounced messages are going to return to a mailbox. You should be able to configure that mailbox by properly setting the headers on the messages you send out. You would then need to monitor that mailbox, or have that mailbox deliver the messages to your program.
I would suggest you consider using VERP for all messages you send out. It will make it much easier for you to identify which email address a particular bounce belongs too. To do this you would need control of your mail server though. It takes some work configuring things.
To answer the question with more detail you need to tell us how your are sending messages, what type of mail server you are running, and how much control you have over the mail server.
On Unix, you can use "procmail" for this. Procmail is a service which can intercept your mails and process them following rules.
If you can access your mail my IMAP, I suggest to look at the Python module imaplib.