RFC 1847: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
In plain English — editorial summary, not part of the RFC
This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.
Document record
- Document ID
- RFC1847
- Published
- October 1995
- Authors
- J. Galvin; S. Murphy; S. Crocker; N. Freed
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 11
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 1848MIME Object Security ServicesCurrent
October 1995
- RFC 2632S/MIME Version 3 Certificate HandlingObsoleted
June 1999
- RFC 2633S/MIME Version 3 Message SpecificationObsoleted
June 1999
- RFC 5750Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate HandlingObsoleted
January 2010
- RFC 5751Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message SpecificationObsoleted
January 2010
- RFC 1844Multimedia E-mail (MIME) User Agent ChecklistCurrent
August 1995
- RFC 1830SMTP Service Extensions for Transmission of Large and Binary MIME MessagesObsoleted
August 1995
- RFC 1867Form-based File Upload in HTMLObsoleted
November 1995
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?