Internet DRAFT - draft-hryckelynck-mail-accepted-previous-sending
draft-hryckelynck-mail-accepted-previous-sending
Network Working Group H. Ryckelynck
Internet-Draft Hubert Ryckelynck
Intended status: Experimental June 7, 2012
Expires: December 9, 2012
Mail Accepted by Previous Sending
draft-hryckelynck-mail-accepted-previous-sending-00
Abstract
Mail Accepted by Previous Sending defines a mechanism by which
incoming unsollicited mails may be rejected or penalized by a MTA if
their sender address domains has never been a destination for the
outgoing mails treated by this MTA.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Ryckelynck Expires December 9, 2012 [Page 1]
Internet-Draft Mail Accepted by Previous Sending June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SMTP responsability notion . . . . . . . . . . . . . . . . . . 5
3.1. Original SMTP responsability notion . . . . . . . . . . . 5
3.1.1. responsibility of the client . . . . . . . . . . . . . 5
3.1.2. responsibility of the server . . . . . . . . . . . . . 5
3.2. gap is growing with the original notion . . . . . . . . . 5
3.2.1. silent dropping . . . . . . . . . . . . . . . . . . . 5
3.3. How to get back to the original notion . . . . . . . . . . 5
3.3.1. Does the return-path exists ? . . . . . . . . . . . . 5
3.3.2. Does the return-path has been sollicited ? . . . . . . 7
4. base format . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 9
5. Command to be used between MTA and BASE . . . . . . . . . . . 10
5.1. To Add information in the base . . . . . . . . . . . . . . 10
5.2. To Check information in the base . . . . . . . . . . . . . 10
6. Store informations about domains in the base . . . . . . . . . 11
6.1. automatically . . . . . . . . . . . . . . . . . . . . . . 11
6.2. accept a domain On demand . . . . . . . . . . . . . . . . 12
6.3. reject a domain On demand . . . . . . . . . . . . . . . . 13
6.4. Directly in the base . . . . . . . . . . . . . . . . . . . 13
7. Check the base and apply policy . . . . . . . . . . . . . . . 14
8. logical view . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Transparent mode . . . . . . . . . . . . . . . . . . . . . 18
9.2. base to be shared . . . . . . . . . . . . . . . . . . . . 18
9.3. Size of the base . . . . . . . . . . . . . . . . . . . . . 18
9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11.1. IP reputation . . . . . . . . . . . . . . . . . . . . . . 20
11.2. SPF, Sender ID and DKIM . . . . . . . . . . . . . . . . . 20
11.3. Mail analysis . . . . . . . . . . . . . . . . . . . . . . 20
11.4. Authentification . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Ryckelynck Expires December 9, 2012 [Page 2]
Internet-Draft Mail Accepted by Previous Sending June 2012
1. Introduction
It is easy to say that mails with, for example, an attempted fraud
content are mails we must intercept.
But for many other type of mail as, for example, marketing mail, it
is very difficult to make the difference between a mail user wants to
receive and a mail he does not want to receive.
In fact, in a lot of cases, the only difference between sollicited
and unsollicited mail is the recipient advice.
With this in mind, it MAY be useful to find a mechanism for users to
choose themselves who will be able to send them some mails.
This mechanism SHOULD of course be implemented in a way the users do
not feel too constrained.
The mechanism described below is an attempt to give an answer to this
problematic.
Mail Accepted by Previous Sending defines a mechanism by which
incoming unsollicited mails may be rejected or penalized by a MTA if
their sender address domains has never been a destination for the
outgoing mails treated by this MTA.
Ryckelynck Expires December 9, 2012 [Page 3]
Internet-Draft Mail Accepted by Previous Sending June 2012
2. Terminology
The term "domain" use in this document has to be understand as the
domain part of a SMTP address (user@domain) and must be a FQDN as
describe in the section 2.3.5 of RFC 5321 [RFC5321].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. These words take their normative meanings only when they
are presented in ALL UPPERCASE.
Ryckelynck Expires December 9, 2012 [Page 4]
Internet-Draft Mail Accepted by Previous Sending June 2012
3. SMTP responsability notion
3.1. Original SMTP responsability notion
In the SMTP RFC [RFC5321], you will find a responsability notion.
3.1.1. responsibility of the client
As Describe in the section 2.1 of RFC 5321 [RFC5321] :
"The responsability of an SMTP client is to transfer mail messages to
one or more SMTP servers, or report its failure to do so".
3.1.2. responsibility of the server
As Describe in the section 2.1 of RFC 5321 [RFC5321] :
"The protocol requires that a server MUST accept responsability for
either delivering the message or properly reporting the failure to do
so"
As Describe in the section 6.1 of RFC 5321 [RFC5321] :
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously.
3.2. gap is growing with the original notion
3.2.1. silent dropping
Because of the huge quantity of unsollicited mail and to avoid giving
more information to those who are sending them, section 6.2 of RFC
5321 [RFC5321] permits in practice silent dropping and more and more
MTAs are configured to drop silently those mails.
3.3. How to get back to the original notion
3.3.1. Does the return-path exists ?
If section 6.2 of RFC 5321 [RFC5321] permits in practice silent
dropping, it also pleads to keep the "delivered or returned" way to
deal with mails.
In this sense, those past years, efforts has been made to find some
ways to check the return path as to stay close from the original SMTP
responsability notion (deliver or notify). You of course need a
Ryckelynck Expires December 9, 2012 [Page 5]
Internet-Draft Mail Accepted by Previous Sending June 2012
return path in case of notify.
But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't
recommend any method.
A return-path is made of two independant elements, the user and the
domain. What can be done if we want to check those two elements.
3.3.1.1. verification of the user part
User part makes sense only for the MTA which finally delivers the
mail.
In the SMTP RFC [RFC5321] the VRFY command permits to ask a MTA about
the user part. But to avoid giving more information to those who are
sending unsollicited mail, the VRFY command has been disabled on most
MTAs. The user part of the sender address is therefore uncheckable.
3.3.1.2. verification of the domain part
There are four verification levels when checking domain :
1. Does the domain exist : First level is to verify if the domain is
declared in the Internet DNS. This can be done by a DNS SOA
Request
2. Does the domain has an MX record : Second level is to verify if
the domain has declared that it can handle mail receiving. This
can be done by a DNS MX request.
3. Does the domain has a declared MTA : Third level is to verify if
the answer of the MX request, formerly the name of the server
which will handle the mails, is properly declared on the Internet
DNS. This can be done by a DNS A request.
4. Does the MTA is answering : Fourth level is to verify if the
answer of the A request, formerly the IP address of the MTA, is
accepting an SMTP connection. This can be done by a connection
on the TCP port 25.
Doing all of these verifications :
o Will consume a lot of ressources. In fact as much work as to send
a notification (except of the data).
o will only prove that your correspondants have a fully compliant
configuration.
Ryckelynck Expires December 9, 2012 [Page 6]
Internet-Draft Mail Accepted by Previous Sending June 2012
o Will not be disuasive for people who wants to send you some
unsollicited mails as the cost to rent an MTA on Internet and to
get a fully compliant Internet DNS configuration is very cheap and
can be change regularly.
Still the only thing that can definitively makes the difference
between a sollicited and an unsollicited mail is the recipient
advice.
3.3.2. Does the return-path has been sollicited ?
3.3.2.1. situation resume
Briefly :
o We MUST NOT drop messages without sending notifications.
o So there SHOULD be a return path for notifications.
o And it MAY be rational to verify this return path validity.
o But today we can only check the domain part of the sender address.
o And it is a very heavy process.
3.3.2.2. Mail accepted by previous sending
To verify the domain and in the same time to be sure the user wants
to comunicate with this domain we could apply the following
mechanism.
When mails are going out :
o Take the domain part of the recipient address.
o Store it, if not already store, in a base as accepted or rejected
domains.
Then when a mail is coming in :
o Take the domain part of the sender address.
o Check in the base if users accepted or rejected this domain
o If some user accepted the domain, we MAY accept the mail.
o If some user rejected the domain, we MAY reject and notify, or
penalize the mail.
Ryckelynck Expires December 9, 2012 [Page 7]
Internet-Draft Mail Accepted by Previous Sending June 2012
This mechanism is fully compliant with RFC 5321 [RFC5321].
As Describe in the section 2.1 of RFC 5321 [RFC5321] : "The protocol
requires that a server MUST accept responsability for either
delivering the message or properly reporting the failure to do so"
And in section 7.9 of RFC 5321 [RFC5321] : "It is a well-established
principle that an SMTP server may refuse to accept mail for any
operational or technical reason that makes sense to the site
providing the server."
And it has the advantage to give the user the possibility to
explicitly declare what is for him a sollicited mail.
Ryckelynck Expires December 9, 2012 [Page 8]
Internet-Draft Mail Accepted by Previous Sending June 2012
4. base format
4.1. Base Fields
This part describes the fields to be present in the base.
+------+ +------+-----------+-------+-----------+-------+----+
| NAME | |Domain|Over-Accept|Accept |Over-Reject| Reject|Date|
+------+ +------+-----------+-------+-----------+-------+----+
| TYPE | | Text | Boolean |Integer| Boolean |Integer|Date|
+------+ +------+-----------+-------+-----------+-------+----+
o Domain : as described in section 3.1 of RFC 1035 [RFC1035].
o Over-Accept : If True, Administrator overrided domain accept.
o Accept : Number of time domain has been accepted.
o Over-Reject : If True, Administrator overrided domain reject.
o Reject : Number of time domain has been rejected.
o Date : Last time record was updated.
Ryckelynck Expires December 9, 2012 [Page 9]
Internet-Draft Mail Accepted by Previous Sending June 2012
5. Command to be used between MTA and BASE
This part describes the commands to be used between MTA and base.
5.1. To Add information in the base
Command : ADD (DOMAIN,ACCEPT,REJECT,DATE)
Return Type : NONE
Description : Add information about a domain in the base.
5.2. To Check information in the base
Command : DOMAIN()
Return Type : BOOLEAN
Description : Does the domain exist in the base ?
Command : OVER_REJECT()
Return Type : BOOLEAN
Description : Did administrator override domain reject ?
Command : OVER_ACCEPT()
Return Type : BOOLEAN
Description : Did administrator override domain accept ?
Command : NB_ACCEPT()
Return Type : INTEGER
Description : How many time domain has been accepted ?
Command : NB_REJECT()
Return Type : INTEGER
Description : How many time domain has been rejected ?
Ryckelynck Expires December 9, 2012 [Page 10]
Internet-Draft Mail Accepted by Previous Sending June 2012
6. Store informations about domains in the base
6.1. automatically
Anytime a user sends an outgoing mail, a filter on MTA intercepts it
and adds the domain part of the recipient adress as accepted in the
base.
+----+ 2-ADD(DOMAIN,1,0,DATE)
|BASE|<---------------------+
+----+ |
|
## MTA ##################################|##
# +------- FILTER -------+ | #
# | +------------------+ | | #
# | | IF(ANY) | | | #
##### 1-SEND | +------------------+ | | #
#MUA#----------------->| +------------------+ | | #
##### # | | |---------+ #
# | | THEN | | 3-DELIVER
# | | |---------------->
# | +------------------+ | #
# +----------------------+ #
############################################
1. Anytime user sends an outgoing mail.
2. MTA intercepts it and adds in base the following informations :
* recipient address domain (if not already in the base).
* parameter ACCEPT="1" to increment the "Accept" base field.
* parameter REJECT="0" to not increment the "Reject" base field.
* Current date to update, if necessary, the "Date" base field.
3. MTA delivers the mail.
Ryckelynck Expires December 9, 2012 [Page 11]
Internet-Draft Mail Accepted by Previous Sending June 2012
6.2. accept a domain On demand
For mail like newsletter to which user never answers, user sends an
outgoing mail with a specific header, a filter intercepts the mail,
and adds the domain part of the recipient adress as accepted in the
base.
+----+ ADD(DOMAIN,1,0,DATE)
|BASE|<-------------------+
+----+ |
|
## MTA ##################################|##
# +------- FILTER -------+ | #
# | +------------------+ | | #
# | |IF(HEADER="ACCEPT"| | | #
##### 1-SEND WITH | +------------------+ | | #
#MUA#----------------->| +------------------+ | | #
##### "ACCEPT" HEADER | | |---------+ #
# | | THEN | | #
# | | |--->3-DROP #
# | +------------------+ | #
# +----------------------+ #
############################################
1. User sends an outgoing mail with an "ACCEPT" header.
2. MTA intercepts it and adds in base the following informations :
* recipient address domain (if not already in the base).
* parameter ACCEPT="1" to increment the "Accept" base field.
* parameter REJECT="0" to not increment the "Reject" base field.
* Current date to update, if necessary, the "Date" base field.
3. MTA drops the mail.
Remark : The number of domains to be declared this way by user would
be in most cases very small.
Ryckelynck Expires December 9, 2012 [Page 12]
Internet-Draft Mail Accepted by Previous Sending June 2012
6.3. reject a domain On demand
To declare a mail as Unsollicited, user sends an outgoing mail with a
specific header, a filter intercepts the mail and adds the domain
part of the recipient adress as rejected in the base.
+----+ 2-ADD(DOMAIN,0,1,DATE)
|BASE|<---------------------+
+----+ |
|
## MTA ##################################|##
# +------- FILTER -------+ | #
# | +------------------+ | | #
# | |IF(HEADER="REJECT"| | | #
##### 1-SEND WITH | +------------------+ | | #
#MUA#----------------->| +------------------+ | | #
##### "REJECT" HEADER | | |---------+ #
# | | THEN | | #
# | | |--->3-DROP #
# | +------------------+ | #
# +----------------------+ #
############################################
1. User sends an outgoing mail with an "REJECT" header.
2. MTA intercepts it and adds in base the following informations :
* recipient address domain (if not already in the base).
* parameter ACCEPT="0" to not increment the "Accept" base field.
* parameter REJECT="1" to increment the "Reject" base field.
* Current date to update, if necessary, the "Date" base field.
3. MTA drops the mail.
Remark : The number of domains to be declared this way by user would
be in most cases very small.
6.4. Directly in the base
The MTA administrator will of course have the possibility to add a
domain directly in the base.
Ryckelynck Expires December 9, 2012 [Page 13]
Internet-Draft Mail Accepted by Previous Sending June 2012
7. Check the base and apply policy
+---++---+
|O|A||O|R|
1.6 +--------|-+-||-+-|
+--------->|dom1.com|F|1||F|0|
| 2.2 |--------|---||---| 2.1
| +--------|dom2.com|F|1||F|0|<--------+
| | 7.2 |--------|---||---| 7.1 |
| | +------|dom7.com|T|0||F|0|<------+ |
| | | 1.2 |--------|---||---| 1.1 | |
| | | +----|????.???|?|?||?|?|<----+ | |
| | | |4.2 |--------|---||---| 4.1 | | |
| | | | +--|dom4.com|F|1||F|2|<--+ | | |
| | | | | +--------+---++---+ | | | |
| | | | | | | | |
1.5 #|#|#|#|#|########## MTA #########|#|#|#|#
+-----------------+ | | | | | | | +--
| # | | | | | | | #
####|# MUA ######## # | | | | | | +----
# | +----+<------+ | | | | | #
# | +--->| IN | # # | | +---------+ | +------
# | |1.4 +----+<--------+ | | | #
# +------+ # # | | | #
# |ACCEPT|<----+ # # +--------+ | +--------
# +------+ 1.3 | # # | | #
# +----+ # # +----------+ | | #
# |NEW |<-----|NEW HEADER|<-+ | #
# +----+ # # +----------+ | #
# +------+ 1.7 | # # | +--->+--------+ #
# |REJECT|<----+ # # | | |REJECTED|-->
# +------+ # # | | +->+--------+ #
# | |1.8 +----+<-----+-----------+<---+ | | #
# | +--->|JUNK| # # |JUNK HEADER| | | +------
# | +----+<-----+-----------+<---+ | | | #
####|############## # | | | | +----
| # +---------------+ | | | | #
+-----------------+ | +-------------------+ | | | #
1.9 #| | | +-------------------+ | | +--
#|#|#|#|############################|#|#|#
| | | | | | |
| | | |5.2 +--------+---++---+ 5.1 | | |
| | | +----|dom5.com|F|0||F|5|<----+ | |
| | | 6.2 |--------|---||---| 6.1 | |
| | +------|dom6.com|F|0||T|0|<------+ |
| | 3.2 |--------|---||---| 3.1 |
| +--------|dom3.com|F|0||F|1|<--------+
| |--------|---||---|
+--------->|dom1.com|F|0||F|1|
1.10 +--------|---||---|
|O|A||O|R|
+---++---+
Ryckelynck Expires December 9, 2012 [Page 14]
Internet-Draft Mail Accepted by Previous Sending June 2012
1.
1. Mail arrives from @dom1.com, MTA sees dom1.com is not in the
base.
2. MTA adds a "NEW" header and sends it to the MUA. A rule on
the MUA identifies the header and puts the mail in the "NEW"
Box.
3. If user clicks on "ACCEPT" button To declare this mail is
sollicited.
4. MUA puts the mail in the "IN" Box.
5. MUA sends an outgoing mail to the domain with an "accepted"
header.
6. A rule on the MTA identifies the header, intercepts the
mail, adds the domain in the base and declares it as
accepted (+1 in the column A).
7. If user clicks on "REJECT" button To declare this mail is
unsollicited.
8. MUA puts the mail in the "JUNK" Box.
9. MUA sends an outgoing mail to the domain with a "rejected"
header.
10. A rule on the MTA identifies the header, intercepts the
mail, adds the domain in the base and declares it as
rejected (+1 in the column R).
2.
1. Mail arrives from @dom2.com, MTA sees in the base domain has
been accepted (column A=1) and never rejected (column R=0).
2. MTA sends it to MUA and MUA puts the mail in the "IN" Box
Ryckelynck Expires December 9, 2012 [Page 15]
Internet-Draft Mail Accepted by Previous Sending June 2012
3.
1. Mail arrives from @dom3.com. MTA sees in the base domain has
been rejected (column R=1) and never accepted (column A=0).
2. MTA adds a "junk" header and send it to MUA. A rule on the
MUA identifies the header and puts the mail in the "JUNK"
Box.
4.
1. Mail arrives from @dom4.com, MTA sees in the base domain has
been rejected 2 times (column R=2) but has also been accepted
1 time (column A=1).
2. MTA adds a "junk" header and sends it to the MUA. A rule on
the MUA identifies the header and puts the mail in the "junk"
Box.
5.
1. Mail arrives from @dom5.com, MTA sees in the base domain has
been rejected 5 times (column R=5) and never accepted (column
A=0).
2. If 5 is more than the limit the administrator fixed, mail is
rejected.
6.
1. Mail arrives from @dom6.com, MTA sees in the base domain has
been rejected by administrator override (column O=T).
2. Mail is rejected.
7.
1. Mail arrives from @dom7.com, MTA sees in the base domain has
been accepted by administrator override (column O=T).
2. MTA sends it to MUA and MUA puts the mail in the "IN" Box.
Ryckelynck Expires December 9, 2012 [Page 16]
Internet-Draft Mail Accepted by Previous Sending June 2012
8. logical view
INCOMING MAIL
|
+--------+
| | FALSE
|DOMAIN()|-------> Add "NEW" header and deliver.
| |
+--------+
| TRUE
|
+--------+
| | TRUE
| OVER_ |------> Reject.
|REJECT()|
+--------+
| FALSE
|
+--------+
| | TRUE
| OVER_ |------> Deliver.
|ACCEPT()|
+--------+
| FALSE
|
+--------+ +--------+
| NB_ | FALSE | NB_ | TRUE
|REJECT()|------>|ACCEPT()|------> Deliver.
| >0 | | >0 |
+--------+ +--------+
| | FALSE
| TRUE +----------> Add "JUNK" header and deliver.
|
+--------+ +--------+
| NB_ | FALSE | NB_ | TRUE
|ACCEPT()|------>|REJECT()|------> Reject.
| >0 | | > MAX |
+--------+ +--------+
| | FALSE
| +----------> Add "JUNK" header and deliver.
| TRUE
+-----> Add "JUNK" header and deliver.
Ryckelynck Expires December 9, 2012 [Page 17]
Internet-Draft Mail Accepted by Previous Sending June 2012
9. Recommendations
9.1. Transparent mode
When a company wants to implement this mechanism. It SHOULD, at the
beginning, activate only the "Automatically" mode (see 4.1) without
applying any policy.
During a period of time, the base will be automatically filled with
accepted domain.
At the beginning the size of the base will grow up very fast.
After a while, when the growing of the base will slow down, the MTA
administrator could then :
o Communicate to users the way to accept or reject domain.
o Start to reject or penalize non previoulsy accepted domain.
9.2. base to be shared
Information in the Base SHOULD be sharable by all MTA in a same
company.
9.3. Size of the base
To limit the size of the base, the Date field can be used to delete
oldest records.
9.4. Notification
If you make the choice, considering the information in the base, to
reject the mail, you MUST return a 5.5.0 code as Describe in the
section 3.6.2 of RFC 5321 [RFC5321].
Ryckelynck Expires December 9, 2012 [Page 18]
Internet-Draft Mail Accepted by Previous Sending June 2012
10. IANA Considerations
This document has no action for IANA.
Ryckelynck Expires December 9, 2012 [Page 19]
Internet-Draft Mail Accepted by Previous Sending June 2012
11. Security Considerations
11.1. IP reputation
Ip reputation mechanism will still protect you against massive
sending. Without this mechanism the domain verification process
could be a target for Deny of service attack.
11.2. SPF, Sender ID and DKIM
It is not garanteed, when a mail which has a sender address from a
domain you previously accepted, that this mail really come from this
domain. For this purpose you may need other mechanism that could be
viewed as complementary like Sender ID [RFC4406], SPF [RFC4408] or
DKIM [RFC6376].
11.3. Mail analysis
Mail analysis is still needed, as a previously accepted domain MAY
have been temporarly corrupted and MAY send you temporarly
unsollicited mail.
11.4. Authentification
The possibility you give to user to authorize a domain just by
sending a mail SHOULD be limited to authentified user.
Ryckelynck Expires December 9, 2012 [Page 20]
Internet-Draft Mail Accepted by Previous Sending June 2012
12. References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[RFC4408] Schlitt, W. and M. Wong, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail", RFC 4408,
May 2006.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
November 2008.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376,
September 2011.
Ryckelynck Expires December 9, 2012 [Page 21]
Internet-Draft Mail Accepted by Previous Sending June 2012
Appendix A. Acknowledgements
The author gratefully acknowledges the contributions of:
S. Moonesamy
Ryckelynck Expires December 9, 2012 [Page 22]
Internet-Draft Mail Accepted by Previous Sending June 2012
Author's Address
Hubert Ryckelynck
Hubert Ryckelynck
40 Avenue de la Grande Armee
Paris, 75017
FRANCE
Phone:
Email: hub.ryck@gmail.com
URI:
Ryckelynck Expires December 9, 2012 [Page 23]
