IETF Secretariat | 1 Apr 21:05 2015
Picon

ID Tracker State Update Notice: <draft-klensin-smtp-521code-05.txt>

IANA review state changed to IANA - Not OK
ID Tracker URL: http://datatracker.ietf.org/doc/draft-klensin-smtp-521code/

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Amanda Baber via RT | 1 Apr 20:21 2015

[IANA #811598] Last Call: <draft-klensin-smtp-521code-05.txt> (SMTP 521 and 556 Reply Codes) to Proposed Standard

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-klensin-smtp-521code-05.  Please report any inaccuracies and respond to the
question below as soon as possible.

IANA's reviewer has the following comments and questions:

QUESTION: In the IANA Considerations section, should "X.10.1" actually be "X.1.10," or is the document
referring to an entry that will be registered by another document?

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Enumerated Status Codes subregistry of the Simple Mail Transfer Protocol (SMTP) Enhanced Status
Codes Registry located at:

https://www.iana.org/assignments/smtp-enhanced-status-codes/

521 will be added to the list of codes associated with the enhanced code entry for X.3.2. A reference to [
RFC-to-be ] will be added to this registration.

and

556 will be added to the list of codes associated with the enhanced code entry for (X.1.10, or an
unregistered X.10.1?). A reference to [ RFC-to-be ] will be added to this registration.

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226)
registry, we will initiate the required Expert Review via a separate ticket when we have a response to the
question above. 
(Continue reading)

Alexey Melnikov | 22 Mar 16:26 2015

TLS server identity verification procedure update

Hi,
I wrote a draft on "Updated TLS Server Identity Check Procedure for 
Email Related Protocols"
  http://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/

This attempts to standardize consistent rules across all email protocols.

I would like to solicit some reviews and also feedback from implementors 
(email client writers, CA operators, tools writers).

Thank you,
Alexey

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

IETF Secretariat | 11 Mar 17:26 2015
Picon

Telechat update notice: <draft-klensin-smtp-521code-05.txt>

Placed on agenda for telechat - 2015-04-09
ID Tracker URL: http://datatracker.ietf.org/doc/draft-klensin-smtp-521code/

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Riaan Olivier | 6 Mar 15:34 2015

New Enhanced Mail System Status Codes

I have been looking and monitoring the Iana page for SMTP Enhanced
Status Codes and read most of the RFC's and drafts related to this.
I started using the RFC to process the the message replies that we
receive from mail servers around the world and I came across a few
discrepancies and have some new suggestions that I think can be added.
Could you please take the following scenarios into consideration

Discrepancies:
===========

Scenarios 1
----------------
The RFC read as follow:

   X.2.2   Mailbox full

   The mailbox is full because the user has exceeded a per-mailbox
administrative quota or physical capacity.
   The general semantics implies that the recipient can delete
messages to make more space available. This
   code should be used as a persistent transient failure.

Iana page shows Associated basic status code as "Not given"

The above states that the code is only useful for a persistent
transient failure, but I believe that the Subject, Detail could be
used as a permanent failure as well. A good example of this is when a
user's mailbox has been full for longer than a period then the Class
could be 5 because the server will already know that the mailbox is
full and that it won't deliver.
(Continue reading)

John C Klensin | 3 Mar 16:21 2015

New/clarified SMTP reply codes 521 and 556

Hi.

Work on the specification to standardize "no mail accepted" uses
for the 521 reply code and to add and standardize the 556 one is
progressing.   draft-klensin-smtp-521code-03.txt was just posted
and, barring some last-minute discovery of problems, an IETF
Last Call should start on it soon.

That work was initiated because of the "null MX" effort but it
not dependent on it.

This is a heads-up to this list of the pending Last Call,
especially for those who don't follow the IETF or IETF-announce
lists.

If you look at it, editorial comments should go to me.  More
substantive ones should probably wait until the Last Call is
announced and then sent to the IETF list and/or IESG.

I'll try to be sure that the Last Call announcement is
circulated to this list also.

    john

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

(Continue reading)

Kai Engert | 25 Feb 16:35 2015
Picon

Idea: Two-Way Mail

Hello,

I'm not sure what's the best place to send this idea to enhance SMTP for
avoiding spam. The ASRG list is no longer active, so I'm trying it on
this list. Please suggest better places if you think it's inappropriate.
I think it might be appropriate, if there's willinglist to adopt. I
understand that many people/groups would have to agree to such an
enhancement of today's SMTP, so let's start by discussing if this
approach could work.

A (draft) writeup of this idea can be found as a PDF file at:
https://kuix.de/two-way-mail/

Very short summary below:
=================================
Email should adopt the both-way opt-in requirement used by many instant
messaging systems, before messages are accepted for delivery.

Require email address whitelists, controlled by the user, managed on the
user's mailbox server.

Find a way to signal contact attempts to the recipient, enabling a user
to discover them and add entries to the whitelist.

Change email delivery from today's store-and-forward approach and switch
to store-notify-and-poll.

Have the destination server retrieve email only if the sender address is
in the recipient's whitelist.

(Continue reading)

Steve Atkins | 1 Dec 02:54 2014

A trivial question about line lengths

RFC 5322 discusses line lengths both in terms of the maximum line length an MTA can be required to handle (998
bytes) but also a more conservative 78 character limit, driven by the requirement to support user
interfaces that are only 78 characters wide.

If I'm wrapping a header by breaking a line with "\r\n\t", and I'm trying to comply with the spirit of the RFC,
how many characters am I allowed to put on the continuation line?

Is it 77, as I have a single tab character already, and I'm allowed 78 total? Or is it 72, as in the glass
teletype world the RFC seems to live in the tab character will consume 8 display characters to the first tab
stop, leaving me another 72 before I run into the right edge of the screen?

Cheers,
  Steve

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Franck Martin | 19 Sep 09:35 2014

Re: [dmarc-ietf] RFC 7372 on Email Authentication Status Codes

I thought we had extended SMTP codes for that. To bring meaning to the rejection. The only thing the client
MTA needs to know is what to do with the message when it is rejected.

I think that's what the xxx should express:
- don't try again
- try again in same or different session
- disconnect and try again later
- disconnect and try again on another MTA immediately
- ok
- ok continue
- ....

Toute connaissance est une réponse à une question.

> On Sep 19, 2014, at 9:28, Alessandro Vesely <vesely <at> tana.it> wrote:
> 
>> On Thu 18/Sep/2014 20:24:38 +0200 Christoph Kluge wrote:
>> 
>> But that isn’t the point.  The question is whether SMTP clients SHOULD also
>> expect a “policy code” in CONNECT and MAY act accordingly, and how this
>> is covered by said RFC.
> 
> Every upcoming authentication method has at some point considered the
> need to color its rejections with its own reply code.  For an older
> snippet on 550 vs 554, see:
> 
>   John C Klensin, [yam] Ambiguities in RFC 5321, 21 Nov 2009
>   http://www.ietf.org/mail-archive/web/yam/current/msg00186.html

> 
> My understanding is that SMTP reply codes serve to guide protocol
(Continue reading)

John C Klensin | 7 Sep 18:28 2014

draft-klensin-smtp-521code-02.txt

Hi.

To promote tidiness, I've just posted
draft-klensin-smtp-521code-02.txt.   It responds to an extended
discussion on the Apps-Discuss list and some on the IETF llst
about the new nullMX spec, error codes, and RFC 1846.  The scope
of the draft itself is intended to be quite narrow -- it updates
RFC 5321 by adding two codes, 521 and 556, to SMTP and defines
the uses for both.  In particular, it takes no stance on whether
dummy servers such as those proposed in 1846 or nullMX DNS
records should be used at all.

I've directed discussion toward this list on the theory that the
substance of the I-D is really an SMTP matter.  I assume the
draft will be handled as an individual submission.

best,
    john

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp

Franck Martin | 21 Jul 04:42 2014

Re: Error in RFC 5321 concerning SPF and DKIM



Toute connaissance est une réponse à une question.

> On Jul 20, 2014, at 16:36, Dave Crocker <dhc <at> dcrocker.net> wrote:
> 
>> On 7/20/2014 5:50 PM, Franck Martin wrote:
>> This specification does not deal with the verification of return
>>   paths for use in delivery notifications.  Recent work, such as that
>>   on SPF [29] and DKIM [30] [31], has been done to provide ways to improve traceability of the message.
> 
> 
> While they do do that, the sentence seems to me a non-sequitor and in
> particular has nothing to do with the return address, per se.
> 
> So my question is how it helps the SMTP specification reader to have a
> sentence like that and to have it there?
> 

I had the feeling that by removing the last sentence you were making too much of a change therefore the
rejection of the errata

Correcting the incorrect sentence may be acceptable for an errata

How is it helpful? By pointing people in a direction for further reading
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
(Continue reading)


Gmane