There is also a reason that HTTP headers look like mail headers. From RFC2616:
HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822
Lastly the stuff before the DATA is actually important. SMTP maintains a separation between “envelope” and “content”. The MAIL FROM and RCPT TO commands at the SMTP level control the email routing between servers (the envelope addresses).
The envelope controls all aspects of delivery, is specified in RFC821 originally (subsequently updated).
What is inside the envelope (the message body, the stuff in the DATA) is an RFC822 formatted message. In principle you could stuff anything in your envelope and it should get delivered, although it looks like RFC821 does specify that it should be RFC822 formatted, which is a slight shame.
The ‘To:’ and ‘From:’ headers in the body need bear no relation to the envelope addresses. They are intended for the recipient, not the mail system.
They are intended for the recipient, not the mail system.
That’s true. But when you decide how to populate them, you need to remember that if the recipient decides to reply, the MUA will use the values in those headers to direct its MTA as to how the reply should be routed. So while they’re not necessarily related to the envelope data of the message in question, they will eventually play a role in how the mail system routes a reply.
It looks like it’s defined in the MIME RFC, specifically section 5 of RFC 2045. Though, there is a note mentioning that Content-Type predates MIME, and was first defined in RFC 1049.
This RFC suggests proposed additions to the Internet Mail Protocol,
RFC-822, for the Internet community, and requests discussion and
suggestions for improvements.
The other comment mentions MIME handling.
There is also a reason that HTTP headers look like mail headers. From RFC2616:
Lastly the stuff before the DATA is actually important. SMTP maintains a separation between “envelope” and “content”. The MAIL FROM and RCPT TO commands at the SMTP level control the email routing between servers (the envelope addresses).
The envelope controls all aspects of delivery, is specified in RFC821 originally (subsequently updated).
What is inside the envelope (the message body, the stuff in the DATA) is an RFC822 formatted message. In principle you could stuff anything in your envelope and it should get delivered, although it looks like RFC821 does specify that it should be RFC822 formatted, which is a slight shame.
The ‘To:’ and ‘From:’ headers in the body need bear no relation to the envelope addresses. They are intended for the recipient, not the mail system.
That’s true. But when you decide how to populate them, you need to remember that if the recipient decides to reply, the MUA will use the values in those headers to direct its MTA as to how the reply should be routed. So while they’re not necessarily related to the envelope data of the message in question, they will eventually play a role in how the mail system routes a reply.
Might want to look at
net/textprotoin the Go stdlib.Re: content type, the M in MIME stands for mail. :-)
Go has a package for reading multipart mime bodies: https://pkg.go.dev/mime/multipart
Thanks! But where is Content-Type as a mail header defined? In which RFC I mean?
It looks like it’s defined in the MIME RFC, specifically section 5 of RFC 2045. Though, there is a note mentioning that Content-Type predates MIME, and was first defined in RFC 1049.
Perfect, thank you!