Internet DRAFT - draft-hryckelynck-writing-rfcs
draft-hryckelynck-writing-rfcs
Network Working Group H. Ryckelynck
Internet-Draft Hubert Ryckelynck
Intended status: Experimental May 14, 2012
Expires: November 15, 2012
Mail Accepted by Previous Sending
draft-hryckelynck-writing-rfcs-04
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 November 15, 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 November 15, 2012 [Page 1]
Internet-Draft Mail Accepted by Previous Sending May 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SMTP responsability notion . . . . . . . . . . . . . . . . . . 6
3.1. Original SMTP responsability notion . . . . . . . . . . . 6
3.1.1. responsibility of the client . . . . . . . . . . . . . 6
3.1.2. responsibility of the server . . . . . . . . . . . . . 6
3.2. gap is growing with the original notion . . . . . . . . . 6
3.2.1. silent dropping . . . . . . . . . . . . . . . . . . . 6
3.3. How to get back to the original notion . . . . . . . . . . 6
3.3.1. Does the return-path exists ? . . . . . . . . . . . . 6
3.3.2. Does the return-path has been sollicited ? . . . . . . 8
4. Identify Previously accepted domain . . . . . . . . . . . . . 10
4.1. Automatically . . . . . . . . . . . . . . . . . . . . . . 10
4.2. On demand . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Directly in the base . . . . . . . . . . . . . . . . . . . 10
5. Store information about previously accepted domain . . . . . . 11
5.1. Use of a dictionnary . . . . . . . . . . . . . . . . . . . 11
5.2. use of an XML tree . . . . . . . . . . . . . . . . . . . . 11
5.3. Use a Dedicated DNS . . . . . . . . . . . . . . . . . . . 13
6. Apply policy to previously or non previously accepted mail . . 14
6.1. Offensive policy . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Return a 5.5.0 code . . . . . . . . . . . . . . . . . 14
6.1.2. Return a 4.5.0 code . . . . . . . . . . . . . . . . . 15
6.2. Defensive policy . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Add a header . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Promote known Domain . . . . . . . . . . . . . . . . . 15
7. Which Strategy for which user . . . . . . . . . . . . . . . . 16
7.1. Private company . . . . . . . . . . . . . . . . . . . . . 16
7.1.1. As a sender . . . . . . . . . . . . . . . . . . . . . 16
7.1.2. As a receiver . . . . . . . . . . . . . . . . . . . . 16
7.2. Public Messagery . . . . . . . . . . . . . . . . . . . . . 16
7.2.1. As a sender . . . . . . . . . . . . . . . . . . . . . 16
7.2.2. As a receiver . . . . . . . . . . . . . . . . . . . . 17
7.3. Commercial site . . . . . . . . . . . . . . . . . . . . . 17
7.3.1. As a sender . . . . . . . . . . . . . . . . . . . . . 17
7.3.2. As a receiver . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. IP reputation . . . . . . . . . . . . . . . . . . . . . . 20
9.2. SPF and DKIM . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. Mail analysis . . . . . . . . . . . . . . . . . . . . . . 20
9.4. Authentification LDAP . . . . . . . . . . . . . . . . . . 20
9.5. Add a specific object or header . . . . . . . . . . . . . 20
9.6. Blacklist a known domain . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Ryckelynck Expires November 15, 2012 [Page 2]
Internet-Draft Mail Accepted by Previous Sending May 2012
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Ryckelynck Expires November 15, 2012 [Page 3]
Internet-Draft Mail Accepted by Previous Sending May 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 November 15, 2012 [Page 4]
Internet-Draft Mail Accepted by Previous Sending May 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 November 15, 2012 [Page 5]
Internet-Draft Mail Accepted by Previous Sending May 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 November 15, 2012 [Page 6]
Internet-Draft Mail Accepted by Previous Sending May 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 November 15, 2012 [Page 7]
Internet-Draft Mail Accepted by Previous Sending May 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 domains.
Then when a mail is coming in :
o Take the domain part of the sender address.
o Check in the base if we have already send some mail to this domain
* If the answer is yes, it means some of our users wants to
communicate with this domain and we accept the mail.
* If the answer is no, none of our users has explicitly, by
sending some mail to it, declared that he wants to communicate
Ryckelynck Expires November 15, 2012 [Page 8]
Internet-Draft Mail Accepted by Previous Sending May 2012
with this domain and then we MAY apply some policy to, reject
and notify, or penalize the mail (see section 6).
Even in the most offensive policy (reject and notify), this mechanism
is fully compliant with the SMTP responsability notion (deliver or
report).
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 November 15, 2012 [Page 9]
Internet-Draft Mail Accepted by Previous Sending May 2012
4. Identify Previously accepted domain
As we say previously, acceptation of domain by a user SHOULD :
o Be possible in a autonomous way.
o Not be time consuming.
The easiest way is to send an outgoing mail to the domain the user
wants to accept.
4.1. Automatically
When a company wants to implement this mechanism. It SHOULD be
possible at the beginning to activate it in a transparent way.
During a period of time, the "accepted domain" base will be
automatically filled.
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 the users the way to accept domain.
o Start to reject or penalize non previoulsy accepted domain.
4.2. On demand
After the mechanism is in service, when user wants to communicate
with a new domain, they simply send an outgoing mail to this domain.
As disussed later in section "security considerations" this
acceptation mail could have specific subject or other specifif header
value.
Remark : As users in a same company will share the "accepted domain"
base, the number of domains to be declared by user would be in most
cases very small.
4.3. Directly in the base
The MTA administrator will of course have the possibility to add a
domain directly in the base.
Ryckelynck Expires November 15, 2012 [Page 10]
Internet-Draft Mail Accepted by Previous Sending May 2012
5. Store information about previously accepted domain
First, it is important to take in consideration that whatever the way
to store the Information about the "accepted domain" :
o This information SOULD be sharable by all MTA in a same company.
o The size and format of the fields that will contain "accepted
domain" MUST be compatible to the size and format as described in
the section 3.1 of RFC 1035 [RFC1035].
o The MTA administrator MUST have the possibility to set directly a
domain in the base.
5.1. Use of a dictionnary
For small companies a Dictionnary MAY be suficient to store the list
of accepted domains.
5.2. use of an XML tree
For an average company, the use of an xml tree to store the list of
accepted domain SHOULD be more efficient.
The xml tree SHOULD then be compatible with the structure of the
Internet domain as described in the RFC 1034 [RFC1034].
Ryckelynck Expires November 15, 2012 [Page 11]
Internet-Draft Mail Accepted by Previous Sending May 2012
You will find below an example of how the tree MAY look.
<root>
<com>
<companyname>
<office>
<department>
</department>
...
</office>
...
</companyname>
...
</com>
<edu>
<schoolname>
</schoolname>
...
</edu>
...
</root>
To limit the size of the tree, administrator SHOULD have the
possibility to limit the number of subdomain level the system SHOULD
take in consideration in the tree.
In the example below the maximum number of level is 2
<root>
<com>
<companyname>
</companyname>
...
</com>
<edu>
<schoolname>
</schoolname>
...
</edu>
...
</root>
Fonctionality to configure a wildcard for an entire branch in the
tree could be useful for the MTA administrator.
Ryckelynck Expires November 15, 2012 [Page 12]
Internet-Draft Mail Accepted by Previous Sending May 2012
The example below show a wildcard for the entire "edu" branch.
<root>
<com>
<companyname>
</companyname>
...
</com>
<edu>
<*>
</*>
</edu>
...
</root>
5.3. Use a Dedicated DNS
For bigger company, it could be interesting to store the information
about accepted domain in a dedicated DNS.
The use of a dedicated DNS could offer some interesting possibilities
to the MTAs administratror like the use of Wildcard to delibarately
accept large range of domain [RFC4592].
Ryckelynck Expires November 15, 2012 [Page 13]
Internet-Draft Mail Accepted by Previous Sending May 2012
6. Apply policy to previously or non previously accepted mail
Of course, "Mail accepted by previous sending" is not the definitive
solution to get rid of unsollicited mail. It has to be seen as a
mechanism that can give useful information. This information can
then be used in policy to filter mails.
6.1. Offensive policy
"Offensive Policy" here means, mail that match the policy will be
directly rejected.
WARNING : You SHOULD carefully check what are your users need before
to apply an offensive policy as described below, because you MAY
reject some sollicited mails. If you are not sure it is preferable
to choose defensive policy (see section 6.2)
6.1.1. Return a 5.5.0 code
If the domain has not been previously accepted, and you make the
choice, based on this information, to reject the mail, you MUST
return a 5.5.0 code as Describe in the section 3.6.2 of RFC 5321
[RFC5321].
Text to be send with the 5.5.0 could be for example :
"550 Your Domain has not been previously accepted"
Whith this method, it is important to keep a trace in the log of who
was the recipient of the mail before to reject a mail which comes
from a non previously accepted domain. So you SHOULD return a 2.5.0
code to the "MAIL FROM:" command and then while you have the
recipient return a 5.5.0 code to the "RCPT TO" command. As Describe
in the section 3.3 of RFC 5321 [RFC5321].
Example :
S: 220 example-server.com Simple Mail Transfer Service Ready
C: EHLO example-client.com
S: 250 example-server.com greets test.com
C: MAIL FROM:<sender@example-client.com>
S: 250 OK
C: RCPT TO:<recipient@example-server.com>
S: 550 Your Domain has not been previously accepted
C: QUIT
S: 221 example-server.com Service closing transmission channel
Ryckelynck Expires November 15, 2012 [Page 14]
Internet-Draft Mail Accepted by Previous Sending May 2012
6.1.2. Return a 4.5.0 code
A 4.5.0 code MAY also be used, if you want to keep the message in the
sender departure queue to let some time to the recipient to accept
the domain.
6.2. Defensive policy
"Defensive Policy" here means, mail that match the policy will not be
directly rejected.
6.2.1. Add a header
A policy can be implemented as follow :
o The MTA accepts the mail.
o And adds a "non previously authorized" header in the mail.
o Then a rule in the users mail box match the header and put it in
the junk mail directory.
Then if the user is declaring that this mail is sollicited, the
domain can then be added in the "previously accepted domain" base.
6.2.2. Promote known Domain
On MTA which uses IP reputation filter, It could be interesting to
implement a fonctionnality that give the possibility to the
administrator to promote a mail that comes from a domain that has
been previously accepted. For example, if the MTA receive a mail that
SHOULD be dropped because it comes from an IP which has a bad
reputation. The administrator could decide to accept mail with a
lower reputation if this mail has a sender address with a domain
which has been previously accepted.
Ryckelynck Expires November 15, 2012 [Page 15]
Internet-Draft Mail Accepted by Previous Sending May 2012
7. Which Strategy for which user
In this part we will talk about what measures SHOULD be taken by, or
what problems could meet those who wants to implement the "accepted
by previous sending" mechanism.
7.1. Private company
7.1.1. As a sender
7.1.1.1. to another private company
If the sender receive a "550 Your Domain has not been previously
accepted" code, he will clearly know his mail has been rejected and
he has to contact the recipient to ask him to authorize his domain.
7.1.1.2. to a commercial site
As user has to subscribe to receive mail from a commercial site, The
commercial site will have no difficulty to authorize their subscriber
domain. And so the subscriber will be automatically authorized to
send mail to the commercial site.
7.1.2. As a receiver
7.1.2.1. from another private company
When a user wants to be reached by a new company, he will only have
to declare the domain.
7.1.2.2. from a commercial site
When a user wants to be reached by a commercial site, he will only
have to declare the domain. This will force commercial site to
specify clearly which domain they use for their sending. This will
promote commercial site that have a fair marketing policy and will
penalize other marketing sender which change regularly their sender
address domain to cross email filtering.
7.2. Public Messagery
7.2.1. As a sender
7.2.1.1. to a private company
As, the domain will be accepted from the moment only one user has
sent a mail to this domain, big public messagery will be quickly and
automatically integrated in the "previously accepted" base.
Ryckelynck Expires November 15, 2012 [Page 16]
Internet-Draft Mail Accepted by Previous Sending May 2012
7.2.1.2. to a commercial site
As user has to subscribe to receive mail from a commercial site, The
commercial site will have no difficulty to authorize their subscriber
domain. And so the subscriber will be automatically authorized to
send mail to the commercial site.
7.2.2. As a receiver
7.2.2.1. from a private company or from a commercial site.
In this case, the problem is that every user of a public messagery is
an independant entity and has no relation with other users.
This means for public messagery that they will have to store separate
information about accepted domain for each user. If not, anybody
could create a mail box and then autorize his domain for all public
messagery users
Also, It is very important for public messagery that the user doesn't
feel constrained in anyway when using one of their mail box. And
they cannot impose rules to their users as a private company could
do.
Public messagery, if they finally decide to implement such mechanism,
WOULD probably choose a defensive strategy like :
o put the "non accepted" mail in the junk mail directory
o accept the domain for the user if he declares a mail from this
domain is not an unsollicited mail.
7.3. Commercial site
7.3.1. As a sender
7.3.1.1. to a private company
Today marketing sender who has a fair policy :
o Only send mail to users who subscribe.
o Send a mail to confirm subscription.
o Activate the user account when he click on a web link
This method could not be apply anymore with the "previously accepted
mail" mechanism.
Ryckelynck Expires November 15, 2012 [Page 17]
Internet-Draft Mail Accepted by Previous Sending May 2012
Marketing sender will have to ask user to send them a mail to
activate their account.
Advantages of such a way to deal with subcription would be :
o To have an explicit subscribtion trace of the user.
o To autorize only the site on which the user has subscribed and not
all the other senders to whom the site MAY give your address.
o To invite marketing sender to not change anytime their sender
email address and so to apply the appropriate policy to keep a
good reputation on their domain.
7.3.1.2. to another commercial site
N.A
7.3.2. As a receiver
7.3.2.1. from a private company
As user has to subscribe to receive mail from a commercial site, The
commercial site will have no difficulty to authorize their subscriber
domain. And so the subscriber will be automatically authorized to
send mail to the commercial site.
7.3.2.2. from another commercial site
N.A
Ryckelynck Expires November 15, 2012 [Page 18]
Internet-Draft Mail Accepted by Previous Sending May 2012
8. IANA Considerations
This document has no action for IANA.
Ryckelynck Expires November 15, 2012 [Page 19]
Internet-Draft Mail Accepted by Previous Sending May 2012
9. Security Considerations
9.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.
9.2. SPF 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].
9.3. Mail analysis
Mail analysis is still needed, as an identified and authorized domain
MAY have been temporarly corrupted and MAY send you temporarly
unsollicited mail.
9.4. Authentification LDAP
The possibility you give to user to authorize a domain just by
sending a mail SHOULD be limited to authentified user. This
authentification MAY be for example realized by a request to your
LDAP server.
9.5. Add a specific object or header
The possibility you give to user to authorize a domain just by
sending a mail could be limited by using a specific subject or a
specific header in the mail.
In this case, an automated fonctionnality SHOULD be implemented in
the user mail client :
o So the authorization of a domain remains easy for the user.
o To guarantee the format of the requested subject or header.
9.6. Blacklist a known domain
In the case a domain previously accepted by a user is declared as an
unsollicited mail sender by some other users. The MTA administrator
SHOULD have the preemptive possibility to blacklist this domain.
Ryckelynck Expires November 15, 2012 [Page 20]
Internet-Draft Mail Accepted by Previous Sending May 2012
10. References
[RFC1034] Mockapetris, P., "Domain names - concept and facilities",
STD 13, RFC 1034, November 1987.
[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.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 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 November 15, 2012 [Page 21]
Internet-Draft Mail Accepted by Previous Sending May 2012
Appendix A. Acknowledgements
The author gratefully acknowledges the contributions of:
S. Moonesamy
Ryckelynck Expires November 15, 2012 [Page 22]
Internet-Draft Mail Accepted by Previous Sending May 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 November 15, 2012 [Page 23]
