Track recipient outcomes and resource limits
05One envelope can have several recipients with different size policies. Keep their acceptance and retry outcomes separate.
The client sends DATA for Alice and receives a final 250 in this chosen example. Bob and Cy were not accepted. Resource controls remain necessary; SIZE does not authenticate a client or encrypt the message.
Source for this drawing: RFC 1870 · Read RFC section 6.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Sending DATA for an accepted recipient does not deliver it to rejected recipients.
- A size-based RCPT 452 permits later requeue to that recipient; a size-based RCPT 552 does not permit later requeue to that recipient.
- A minimal client may compare an advertised fixed maximum without declaring MAIL SIZE, but loses early temporary and per-recipient size checks.
- SIZE reveals policy and can help crude denial of service. It provides neither authentication nor encryption.
The three recipient results follow the shape of RFC 1870’s example using fictional addresses. No messages are sent by this guide.
Read the RFC section ↗