search

ietf-wg-emailcore / emailcore

3 stars 0 forks source link

Recommended SMTP extensions #40

Open ietf-svn-bot opened 3 years ago

ietf-svn-bot commented 3 years ago

owner:alexey.melnikov@isode.com type_task | by alexey.melnikov@isode.com

Suggested SMTP Extensions (MUST/SHOULD/mention/don’t mention):

8BITMIME (RFC 6152) PIPELINING (RFC 2920) Enhanced Reply Codes (RFC 5248)

Issue migrated from trac:40 at 2022-01-31 12:37:01 +0000

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com commented

Also consider:

DSNs (RFC 3461) SMTPUTF8 (a.k.a. EAI) (RFC 6531)

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com commented

Initial suggestion:

8BITMIME (RFC 6152) - MUST Enhanced Reply Codes (RFC 5248) - MUST DSNs (RFC 3461) - MUST

PIPELINING (RFC 2920) - SHOULD SMTPUTF8 (a.k.a. EAI) (RFC 6531) - SHOULD

ietf-svn-bot commented 2 years ago

@alexey.melnikov@isode.com commented

Discussed @ IETF 112. Broad support for this in the meeting.

Note that the above requirements are somewhat stronger than what is currently in RFC 6409, where all but SMTPUTF8 are "SHOULD"s.

klensin commented 2 years ago

This never made it into Appendix G (and that is probably why I opened #64); Have dealt with that in the working draft of rfc5321bis-11. Note that a SHOULD for 8BITMIME has been added to Section 2.4 on the basis of prior WG discussions. Making it a MUST would require additional discussion.

As to 6409 (Message Submission), much of the idea there was to be able to define different requirements, especially on the receiver side, than SMTP requires in transit, noting that the sender side of a Submission Server is required to be sure that everything it sends onto the public Internet is SMTP-conforming.

In general, I think requirement levels for extensions (and whatever associated discussion is needed) should be in the A/S, with only those extensions that seem connected to statements that are in 5321bis for other reasons included there (and probably repeated/mentioned in the A/S anyway). Up to the WG of course, but this is an area where both the "minimal change" and "5321bis is already too long and complicated" issues apply.

klensin commented 2 years ago

Following up on the above. please review -fc5321bis-11 when it appears.

After a more comprehensive review, it appears that the extensions listed are already discussed in rfc5321bis with requirements text ("" indicates the Section containing the actual requirement): 8BITMIME (Section 2.3.1, 2.4), DSNs (Sections 3.6.2, 4.5.5) Enhanced Reply Codes (Section 2.3.7, 3.5.1, 4.2, 4.3.2(very weak SHOULD)) In addition, the following are mentioned informatively (no requirements text): PIPELINING (Section 2.1) SMTPUTF8 (Section 4.1.2 (in rfc5321-11))

Please review the above but I believe that, if the text in rfc5321bis-11 is acceptable, this ticket can be closed and/or dealt with in the A/S as suggested below.

I suggest that we not add further recommendation/requirement text to rfc53121bis but instead deal with it in the A/S as appropriate. In particular, relative to the proposed MUST requirements above, I would urge being very cautious about rfc5321bis and features that are not universally supported today. Enhanced Status Codes are a particularly good example: many contemporary (and conforming to 5321) SMTP implementations appear to not support them. Imposing a new requirement that invalidates them should, procedurally, take us back to Proposed Standard. A better plan would be to leave/specify them as SHOULD (no change) and then use the A/S to explain why they are a really, really, good idea (or that not supplying them is a terrible idea).

toddherr commented 9 months ago

Have discussion on list as to whether or not A/S covers these topics, then close the ticket.

ksmurchison commented 1 month ago

Levine 2 July, 2024:

Sec 2.4 says you MUST implement Deliver Status Notifications [RFC3461].

This is wrong, and not just because Deliver is missing the "y". RFC3461 is about the EHLO keyword DSN which enables MAIL FROM keywords RET and ENVID and RCPT TO keywords NOTIFY and ORCPT.

The only large mail system I know that announces DSN is Microsoft and I wouldn't count on them getting it right. Gmail doesn't, Yahoo doesn't, Comcast doesn't, Fastmail doesn't, Tucows' hostedemail doesn't. Exim appears to support it but I'm pretty sure Postfix doesn't.

Please just take it out.

ksmurchison commented 1 month ago

Levine 2 July, 2024:

Sec 2.4 says you MUST implement Deliver Status Notifications [RFC3461].

This is wrong, and not just because Deliver is missing the "y". RFC3461 is about the EHLO keyword DSN which enables MAIL FROM keywords RET and ENVID and RCPT TO keywords NOTIFY and ORCPT.

The only large mail system I know that announces DSN is Microsoft and I wouldn't count on them getting it right. Gmail doesn't, Yahoo doesn't, Comcast doesn't, Fastmail doesn't, Tucows' hostedemail doesn't. Exim appears to support it but I'm pretty sure Postfix doesn't.

Please just take it out.

Nerenberg concurs:

Another reason for nuking it: requiring this for embedded devices (think printers, scanners, fax machines) is nonsensical.