From: <jeremy+spf(_at_)doupe(_dot_)com>
I had the same problem when I sent a few tests. I'll assume you sent
the mail via "telnet" to port 25 (or something similar). You need to
include at lease the following 2822 headers before hotmail will deliver
the mail (they otherwise put it to /dev/null apparently):
Unfortunately, in direct violation of RFC 2821. Lets just hope this illegal
operation does not catches on with new mail servers following Microsoft.
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a positive completion status (2yz code)
after the DATA command is completed with <CRLF>.<CRLF>, it accepts
responsibility for:
- delivering the message (if the recipient mailbox exists), or
- if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at
intervals as specified in section 4.5.4.
- if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP
MAIL command).
4.1.1.4 DATA (DATA)
Receipt of the end of mail data indication requires the server to
process the stored mail transaction information. This processing
consumes the information in the reverse-path buffer, the forward-path
buffer, and the mail data buffer, and on the completion of this
command these buffers are cleared. If the processing is successful,
the receiver MUST send an OK reply. If the processing fails the
receiver MUST send a failure reply. The SMTP model does not allow
for partial failures at this point: either the message is accepted by
the server for delivery and a positive response is returned or it is
not accepted and a failure reply is returned. In sending a positive
completion reply to the end of data indication, the receiver takes
full responsibility for the message (see section 6.1). Errors that
are diagnosed subsequently MUST be reported in a mail message, as
discussed in section 4.4.
4.5.3.2 Timeouts
DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply. When the receiver gets
the final period terminating the message data, it typically
performs processing to deliver the message to a user mailbox. A
spurious timeout at this point would be very wasteful and would
typically result in delivery of multiple copies of the message,
since it has been successfully sent and the server has accepted
responsibility for delivery. See section 6.1 for additional
discussion.
6.1 Reliable Delivery and Replies by Email
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. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage.
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. Obviously, nothing in this section can or should
prohibit local decisions (i.e., as part of the same system
environment as the receiver-SMTP) to log or otherwise transmit
information about null address events locally if that is desired. If
the address is an explicit source route, it MUST be stripped down to
its final hop.
Finally, since 1986, the US ECPA has had provisions in regards to "user
expectations." It was basically model on online systems accepted a posted
message by a user but "mysteriously disappeared" for one reason or not.
The basic rule of thumb is:
a) Display a System Policy
b) if rejected and notify user immediately if not acceptable
c) If accepted, delivery the message or provide reason for non delivery
after some specified period.
This guideline based on online systems was carried on with the advent of
store and forward systems as well, such as SMTP and other mail transports
systems as well.
SMTP level rejection satisfied item b above.
SMTP mail acceptance , delivery or delay notification satisfied item c
above.
This is how it always been since 1986. There were many court cases based on
this, mostly on the online world (AOL, CompuServe, Prodigy, etc), but it all
boils down to how much harm is done. No harm, no foul. No money in it, no
lawsuit.
But now we have Microsoft changing the fundamental traditional rules that
has been in place for decades. It will be inevitable that Microsoft will be
sweet targeted for violation of US ECPA with some censorship claim or
mal-practice claim.
My main concern is how others will follow this behavior before realizing it
is mistake .
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com