Sending an email 101 - real basic question about attachment size limits, if any

When you type in experts-exchange.com in a web browser, theres all the work of resolving the name into an ip address and then your packets are sent from your computer to the EE web server and vice versa, going through routers around the web, right?

Contrast that with an email?  I was explaining to someone that large attachments in an email might cause the email to not be delivered as it routes its way through the web. Then I wondered... is the email actually going through  mail servers on the web and being reforwarded? Or just routers (on the backbone?). If it's just routers, do they actually care how big the total email is? It's just a lot of packets being sent in the same direction.

ie - is there really a limit to an attachment size limit in email OTHER THAN at the sender or receiver email server?  Yes, the sender server or receiving server can set limits to the size of the attachment.  But after resolving the MX record and sending to the receiving server.... what could get in the way?

THANKS!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nociSoftware EngineerCommented:
yes the mail is realy going through mailservers... not like routers more like a regular MTA (Mail Transfer Agent aka Mailserver)
MTA's DO impose a limit on this. The Lower limit on this is 10MB. raw size of the E-mail including headers etc.. Because of base64 encoding used for attachments the size of any file will become ~4/3 of the original size. Also each attachment adds somewhere between 100-400 bytes of  file header & separation info.
The standard for transfering files over mail is called MIME (or S/MIME) for secure variant.
Any mail is completely readable on each MTA except for S/MIME parts or PGP encrypted parts. PGP is pasted as text in the message not a "real" attachment.

Any MTA in between the originating mailserver and the ultimate target mailserver is effectively Receiving the mail, seein it needs to be relay'd en then sends it again (with a bit of headers added) the extra headers are At least a Received header, but may also contain SPAM scores/verdict check update etc.

Some MTA's do allow bigger sizes it realy is up to the systems manager of the MTA.
Besides MTA's  you may pass firewalls (or not pass them).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
BeGentleWithMe-INeedHelpAuthor Commented:
Noci:   Thank you very much!

I Will Google and read up on the web about MTAs, but just a quick thought if you wanna answer,

are they provided by the companies that maintain the backbone of the Internet? Or could anybody put an MTA on the Internet and start reading other peoples mail? I know - email is readable if it’s not encrypted  as it travels the Internet.

Any idea why the web is like that? That mail gets received somewhere in the middle all the packets are assembled into the email and that it sent out again. Rather than lile uploading a file to dropbox or a page request for a webpage or a webpage reply… The packets go through different devices on the way between the endpoints but I don’t think there’s anything in the middle assembling the web page you requested before it sends it onto you, right?

And a kind of rhetorical question – I would think thered be a Internet standard for how big an attachment can be… I think Gmail allows 25 MB, but that’s pretty worthless right? You’re 25 MB attachment email got lost somewhere in the cloud :-) if it’s sent anywhere other than another gmail account?!  Or even then if the email has to leave one Gmail server farm to go to another.  that email might get dumped because of the size of the attachment as it travels the web to get to other gmail server?  Yeah Gmail probably has their own paths but I think you get my point?
Dave BaldwinFixer of ProblemsCommented:
From a user point of view, email gets sent from your client to your mail server which then sends it to their mail server which serves it to their client.  However, along the 'path' like ALL internet traffic, it goes thru multiple packet relays.  A 'traceroute' or 'tracert' will show you an example of the intermediate servers along the path.  The intermediate servers pass along packets but do not 'assemble' them into messages or web pages.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

atlas_shudderedSr. Network EngineerCommented:
An MTA is an SMTP server.  Generally, there will be only two involved in the transaction.  One on the sender side, one on the receiver side.  I say generally because I suppose it would be possible to traverse multiples on the way out or the way into a particular MX domain, but again, these would be in either the sender or the receiver domain.  In other words, if you send an email from your desktop to an address @gmail.com, your mail is not going to have a layover @yahoo.com on the way.

Here's the map:

1.  You build an email in your client
2.  You click send
3.  Said email is forwarded from your client to your local MTA (SMTP server).
4.  Your SMTP server performs an MX lookup to determine the address of the authoritative MTA for the MX domain you are sending to (i.e. @gmail.com)
5.  Your SMTP server then packetizes your email, drops it onto the wire with the IP header noting a destination address of the returned MX lookup.
6.  Your email in packets, now traverses the great wide Internet, a VPN, etc. (whichever path is selected by the next gateway in its path) until it reaches the destination IP provided by the MX lookup.
7.  Now, this IP may be an alias pointing to an intermediary such as a spam filter, etc. but it is still nonetheless inside your receiver's domain at this point.
8. Once it has passed any intermediary hops in your recipeint's domain, it is handed to their SMTP server and then either to their client direct or an IMAP/POP server for retrieval.

Now, where can filtering occur?

By attachment size, you can be filtered at your local domain (attachment size limits on your SMTP server, outbound service filters - DLP, etc.) or on the receiver's side, in their SMTP/MX domain (attachment size restrictions on their SMTP server, spam filter, etc.).  A router will not limit you on the size of your attachment.  Ever.  It may limit the amount of traffic it sends over a given interface but it isn't re-assembling your email to check your attachment size.  A router neither cares, nor is it capable.  Layer 3 and no higher.  Also, your email isn't going to traverse transparent SMTP servers and MTA's as it traverses the Internet so they can inspect and enforce your attachment size.  Think about it.  If either of these were happening, you'd have a broken Internet.

Instead, if you are having file attachment sizes getting chomped, then check your local SMTP settings or get in touch with the receiving domain.

If instead, you are trying to talk to one of those users that insists they have to send a 100MB attachment on every other email, why not just explain to them that they are killing the local WAN connection and impeding other local users.  That or police smtp on the router.
nociSoftware EngineerCommented:
@Dave.... Traceroute will not show MTA's just normal IP routers.
and there is a string of such routers between each MTA...
MTA's can be traced by checking all receved lines in the mail header
(View Header, and scroll Down, EVERY MTA leaves a Received that may be more then just sender & receiver MTA.)
many mails travel from web services to local server and from then on through MTA's.
E-Mail is a type of processing called Store & Forward.

Here a mail that is passed through 6 MTA's: some address & names removed ...

Received: from [2001::
Received: from bsmtpdelivery8
Received: from mail15.eventbrite.com (mail15.eventbrite.com [184.106.14.63])
Received: from prod-core-mta6.aws-us-east-1.evbops.com ([50.19.117.164])
Received: from prod-task-app6.aws-us-east-1.evbops.com (prod-task-app6.aws-us-east-1.evbops.com [172.21.214.221])
Received: from prod-task-app6.aws-us-east-1.evbops.com (localhost [127.0.0.1])

(Received: from entries typicaly have move than one line).
The bottom one is the first MTA, and appearantly this is an application that has localhost as first stop.
Oh by the way, these received lines were lifted from a mail that was in the mail transit area (spool area).

@atlas_shuddered:
There are a lot of  organisations that have their MX records point to a mail scrubber agent.
And shit mail scrubber then delivers all acceptable mail to the final organisation. IN above example the  bstmpserver8 server does that.

A description is SMTP is in https://www.ietf.org/rfc/rfc2821.txt   (RFC 2821).
atlas_shudderedSr. Network EngineerCommented:
Lets actually read and de-obfuscate the above header

1. Received: from [2001::  Delivery node - localhost - IPv6 address - still in eventbrite.com domain
2. Received: from bsmtpdelivery8  By admission, mail scrubber but still technically in eventbrite.com domain
3. Received: from mail15.eventbrite.com (mail15.eventbrite.com [184.106.14.63])  MTA/MX edge for domain eventbrite.com
4. Received: from prod-core-mta6.aws-us-east-1.evbops.com ([50.19.117.164])  MTA/MX edge for domain evbops.com
5. Received: from prod-task-app6.aws-us-east-1.evbops.com (prod-task-app6.aws-us-east-1.evbops.com [172.21.214.221])  Sender local node/Delivery host - still in evbops.com domain
6. Received: from prod-task-app6.aws-us-east-1.evbops.com (localhost [127.0.0.1])  Sender local host.  Notice same name and domain as 6 above

There is no intermediary, unknown MTA involved above.  Each and every hop in that header is:

1.  Specifically engineered to push traffic in the direction is is traveling
2.  In one of either two mail domains
3.  Performing an engineered function specifically for one of those two mail domains

Again, the routers don't care if you are sending FTP, SMTP or IGA green stamps over them as long as they are using TCP/IP.  They only care about the destination IP and neither care nor are able to determine, what is actually contained within the overall file being transmitted at higher layers.  Layer 3, no higher.

And again, short of the NSA snorting or being a blind pass-through, email destined for somebizaardomain.com does not make pit stops at pizzahut.com, gmail.com or somerandomMXdomain.com as it makes it's way there, unless - and I stress this - it has been specifically engineered to do so by either the sender or receiver and then, if it has been so engineered, once it travels beyond that entities ability to control, it will go directly to the IP listed in the MX record of the receiver domain.  In other words, no intermediary without hostlookup meddling.
nociSoftware EngineerCommented:
To correct this.
There are 2 false assumptions:
bsmtpdelivery8 is NOT with  eventbrite., it is a 3rd party. that i don;t want to show.
and 2001;: is my upstream mailserver (smarthost), the last step (my MTA) was removed as well.

There are indeed no pitstops, but there are relays involved. I run a relay for a few mail customers we only manage their infra.
They have their own ISP, Hosting etc. so multi parties might stil be involved, mostly by choice.
Wrt. routers, not only TCP/IP but all IP protocols (including ICMP, UDP, SCTP, ESP, GRE, ..... TCP is just one of those)
And services within those protocols like SMTP, FTP,DNS using TCP   DNS using UDP,  IPSEC+IKE using ESP+UDP


For the NSA it is even easier to tap all traffic on an exchange (they do for Foreign traffic, as seen from USA standpoint).
But there are easier attacks possible, if the BGP routes  get redistributed a little (it has happended by "accident"...)  that traffic intended for USA when somewhere through the middleeast due to a routing error.
and the target can imporsonate anyone without the source ever noticing. (except for maybe lack of traffic).
atlas_shudderedSr. Network EngineerCommented:
noci -

You host services for a customer.  Again, you are acting within their mail domain or they are acting in yours, you aren't just randomly inserting yourself into the mix.  Engineered.

NSA - they snort the traffic from the wire, bring up above layer 3, sift it, shred it, whatever.  Not a relay, its a path mirror.

BGP - this is a routing protocol, on a router, not a relay.  Again, a router operates at layers 1 - 3.  Physical connection, MAC addresses and IP's are the only things that they care about.  If email is captured due to route poisoning (not redistribution - this is the practice of transferring/sharing route information between different routing protocols, domains, areas, AS's, etc.), it is still not at the router - the attacker has to snort that traffic in through a pass through device via mirror, like the NSA does.  Again, not the router and specifically engineered/manipulated - and even more importantly, there is still no MTA involved.

What target?  Again, what you are describing by definition requires the manipulation of traffic and what you describe is so involved it only happens in two cases - 1.  Specific, dedicated, directed attacks that which chances of going unnoticed rapidly diminish toward zero and 2.  Crime dramas like NCIS, Criminal Minds and Scorpion, in which no one but the actors and the edge of seat watchers care about to begin with.

But lets assume that what you propose is plausible.  You set up an MTA/SMTP server on the interwebs with the nefarious intention of grabbing my email for my mail domain @weareofftheresnow.com.  The only way you can get email to that SMTP server is if you announce yourself as authoritative for my domain (we shall forego getting into all the hoops to jump through to actually get this to work and give it the achievement) and thereby poison DNS in all domains globally - in other words you have to poison the global resolvers - no mean feat.  Once you accomplish this, congratulations, all my domain's email will come to you.  Now, in order to insure that you are able to continue passing email traffic to me (to remain undetected) after you have captured it, you would have to contact me and convince me to build a trust relationship with you, some random person who has upstaged my MX SOA.  Which is more likely, I comply or ask if you can hold, click line 2 and start dialing the FBI?  Let's say you don't make the call.  That means you keep all my mail.  Just how long would it take for your users to begin asking questions if they stopped receiving emails and how long would it take for that to escalate to you trying to figure out why you're not receiving either?
Now, lets assume that my domain is from a small knot wood gnurler in Podunk, Wherever.  You could probably get away with it, maybe for quite a while but - just what kind of criminal mastermind would go through all that trouble for such a low yield?

Again, not impossible but, in order to pass multiple MTA's and SMTP servers, it has to be specifically engineered by either the sender or the receiver.  In either case, if your message bounces, you are going to be talking to one or the other to determine what the limitation is to either work around it or get it raised.
nociSoftware EngineerCommented:
Even if intermediates are "engineered" in the equation (not always by choice),  then there is still control there. So it is still out of control as far as the sender & recipient are concerned.
It passes that MTA, and on THAT MTA mail is visible, inspectable,, hell we ask them to inspect it to catch SPAM & virusses.

In parts of the internet industry it is  a custom to get more from the data transferred then just forward it.
Gmail harvests content for targetted advertising. You get the gmail service in return for that.
Other advertisement firms harvest the URL's where their advertisement is shown, as thank you you get an image & tracker.
The harvest is URL's of all pages that have been visited by that same user through various sites with the user identified by a cookie.
There is no need to push a facebook-"like" button, fetching the image already told facebook that you visited, whether you have an account there or not.
Some are more hidden than others... there are a few thousand of those data collection brokers.
Browser extensions like umatrix, ghostery show those for browsers.
I think i can trust the 3rd party bstmpdelivery8..... to not harvest data from mails i can never be sure.

It's not that transparent. I knew of a setup where all mail through an ISP in EU went through messagelabs servers in the US.
So mail from one EU country to another did take a detour through messagelabs servers... after some EU legislation changes those servers went (i think) to UK. (Not that That will help in a year or so after brexit they need to establish some shop with in the EU and move at least in part from UK). The ISP was a joint venture between US & EU companies.

E-Mail is still comparable to (picture)postcards, whereas letters in closed envelopes only have a n equivalent in PGP or S/MIME.
BeGentleWithMe-INeedHelpAuthor Commented:
Uh... thanks guys!!! what you are talking about is WAYYYYY above my pay grade.

To summarize?  Atlas, you are saying the only 2 places that attachment size is checked is at the sending end's mail server and the receiving end's spam filters / mail server?

And noci - you are saying there's other places on the web as the email is sent from sender to receiver where that midpoint says 'that's attachment is too large?'

I thought I had heard of Noci's idea (if I said it right), but then wondered if that's accurate (that the email gets re-assembled completely along the route for that mid point to see the entire attachment size and hence, this question.

tracert is checking 1 packet, right?  an email is loads of packets conceivably taking different routes to get to the reiceving email server?

I guess the issue of limit of attachment size (according to atlas) is that you might not know the receiving end's max attachment size it would accept?  So THAT's the guiding thought on 'don't attach really big files'?
Dave BaldwinFixer of ProblemsCommented:
No, 'tracert' is a method for checking and finding the intermediate servers along a path.  Many packets are sent to develop the information.
atlas_shudderedSr. Network EngineerCommented:
@Be.  

If you are asking so you can address a concern with a user, if you manage your own email, then you can limit attachment size or just let their attachments bounce on the far end. If you are concerned about bandwidth, QOS the traffic.

But, if you are just trying to educate them, don't try to tell them their traffic is going through intermediary, invisible equipment on the Internet that is going to dump their messages because of attachment size. Doing so is not just disingenuous, it is also patently incorrect.

Yes, attachment filtering occurs within the sender or receiver mail administrative domains. Yes there are exceptions to this but as has been beaten to death on this thread, those exceptions are wildly speculative and rare.

On the trace route point. ICMP is the underlying protocol. In most cases, there are between 3-5 packets sent per hop. Trace route measures hops, min, max, median delay in some implementations. It all depends on the platform.

Hope its all been helpful.  Good luck!

Last post to this topic.

Cheers
nociSoftware EngineerCommented:
Relaying on behalf of other parties is more rarely nowadays  as many site have excelent connection to the Internet, that said it is still done.
That said some ISP's enforce this.  in a chain the MTA that has the smallest size setting determines the size.
relaying outside "administrative" domains might still happen for mail scan. Each relay has it's own limitiations.

A mail is sent one hop at a time, as a complete message, from MTA to MTA.
Between 2 MTA's it is sent in packets according to IP route settings. (mostly through port 25). You can see this in action when using a sniffing tool like tcpdump or wireshark on an MTA or router in a path.

(unix based traceroute uses UDP in stead of ICMP, but optionaly can use ICMP)  and both UDP & ICMP traceroutes may be off so for better accuracy try tcptraceroute with the correct port number because a lot of sites now use "policy routing" where depending on service involved routing may be different.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Routers

From novice to tech pro — start learning today.