- Dec 2019
-
tools.ietf.org tools.ietf.org
-
especially in conjunction with facilities that receive mail via POP3 or IMAP
Could as well specify IIoT devices here.
-
A very common case in the Internet today involves submission of the original message to an intermediate, "message submission" server, which is similar to a relay but has some additional properties; such servers are discussed in Section 2.3.10
Section 2.3.10 doesn't actually treat submission.
-
A "gateway" SMTP system (usually referred to just as a "gateway")
RFC 5598, Section 5 considers Mediators, which includes Alias, ReSender, Mailing Lists, Gateways, and Boundary Filter.
-
SHOULD not
That should be SHOULD NOT (uppercase). See yam ticket 13.
-
This section is new with 5321bis
I think this solves yam ticket 11.
-
Mailing Lists and Aliases
Perhaps, this section should be named Forwarding and include a sub section on Backup MXes? Yam ticket 10.
-
source routes
Could this digression on source routes go to an appendix? (Yam ticket 8)
-
In addition
Per Section 7 of RFC 6409 Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
Does that deserve an extra bullet?
-
Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case
This sentence does not belong here, but in Section 3.2 List, where it is repeated exactly like. See yam ticket 6 and 9.
-
next subsection
Is it worth to give up good English to follow the fitfulness of htmlization? See yam ticket 5.
-
Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case.
This is the sentence referenced from Section 4.4 Trace information.
Forwarding is not the title of this subsection. See Erratum 1820.
-
it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it.
I guess this circumvoluted wording is to avoid to specify MDA. See item 1/3 of Erratum 3447.
-
There are circumstances, contrary to the intent of this specification, in which an SMTP server may receive an indication that the underlying TCP connection has been closed or reset. To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared.
TCP reset is completely different from RSET command. This text can be moved to an appropriate section. See Erratum 1851.
-
sender- SMTP
Shouldn't this be SMTP client?
The correction in the text is from Erratum 4198.
-
Proposed erratum (4055) suggests that DKIM and SPF have nothing to do with this and that everything after the first sentence should be dropped. An alternative would be to tune the texts.
Even if, given the cost of verifying the return path, one would choose to limit the verification to non-authenticated messages, it is a totally heuristic choice, not worth the length it would take.
-
- Mar 2017
-
tools.ietf.org tools.ietf.org
-
The report itself contains data about messages addressed to users at gmail.com and many other domains hosted by Google
This implies a receiver cannot attempt to match received reports with the mail it sent. Looking up Public Suffix List does not disclose that google and gmail belong to the same organization.
-
DMARC aggregate reports should use UTC day boundaries for the reporting intervals.
Reports can be sent some time after the end of the interval. (A difficulty is to set a cron job at UTC, so I send with one hour delay.)
-
The receiver could use the following data points to better understand their incoming email traffic:
How does a receiver collect that data?
-
Incremental Roll-Out.
A possibility is to enable/disable honoring DMARC policy on a per-domain basis (I currently have globally disable and enable on a few domains which send only transactional mail).
Perhaps, the possibility to override the remote policy should also be considered.
-
The collection of feedback statistics for use in generating DMARC aggregate likely presents the most opportunity for new development.
An important consideration is the sending domains database. SMTP specification need no database (except the ubiquitous DNS). DMARC needs some kind of database in order to send reports. This need should be enounced early in this document. Many practices can then be expressed in terms of database operations and structure.
-
- Oct 2016
-
deepmind.com deepmind.com
-
DNC stores 'temporal links' to keep track of the order things were written in
This would be the definition of "temporal", in a cosmology-oriented theorization.
Tags
Annotators
URL
-
- Sep 2016
-
tools.ietf.org tools.ietf.org
-
several
two, actually
-
Figure 1 illustrates the relationship between verification conditions and Authentication-Results.
It should at least be stated that SPF and DKIM records can, in turn, exist in the domain's DNS or not.
-
-
www.internetsociety.org www.internetsociety.org
-
Data centers
Should we not mention the possibility that someone plainly hosts a server at home? For one thing, the security of not allowing remote shells at all is unbeatable.
-
- Jul 2016
-
tools.ietf.org tools.ietf.org
-
All public annotations made on Hypothesis are explicitly in the public domain. See also the Hypothesis Terms of Service, https://hypothes.is/terms-of-service/. Note that Hypothesis itself is a non-profit organization.
That seems to imply that the IETF should use hypothes.is for the service. That is just one possible annotation providers. If the experiment is successful, annotations will presumably have to be moved to an IETF server and use Annotator directly.
-
-
tools.ietf.org tools.ietf.org
-
A Standard for the Transmission of IP Datagrams on Avian Carriers
Can U see 2 annotations on this title?
-