Joe <j...@jretrading.com> writes:
> Yes, although there should still be an audit trail. As I said to Harry
> the other day, if you have a message ID from the receiving server you
> (probably) can chase it up, and no reputable anti-spam software will
> drop a message without keeping a log stating that it has done so. It is
> generally possible to find out why a legitimate message was dropped,
> though of course, somewhat after the event.
Dropping a message is a malfunction.
>> And... these things ARE covered, at least in part, by RFCs"
>>
>> RFC5321 (latest SMTP spec), Section 6.2. (Unwanted, Unsolicited, and
>> "Attack" Messages) makes for interesting reading.
>>
>> For example:
>> "As discussed in Section 7.8 and Section 7.9 below, dropping mail
>> without notification of the sender is permitted in practice. However,
>> it is extremely dangerous and violates a long tradition and community
>> expectations that mail is either delivered or returned. If silent
>> message-dropping is misused, it could easily undermine confidence in
>> the reliability of the Internet's mail systems. So silent dropping of
>> messages should be considered only in those cases where there is very
>> high confidence that the messages are seriously fraudulent or
>> otherwise inappropriate."
>>
> There Is No Alternative. If a message is malicious spam, then it is
> absolutely certain that the 'From:' is forged, and no messages should
> be sent to it. There is some spam which might be called 'genuine', in
> that a real business has sent it under the impression that UCE is a
> legitimate marketing tool. In those cases only, a bounce message would
> be appropriate, but sometimes even I'm not sure whether a spam falls
> into this category.
You are mistaken. You send a bounce only for messages you accepted and
then can not deliver. Such cases are extremely rare, and if it happens,
you need to investigate.
You do not accept messages you can not deliver unless you are relaying
them. If you can not deliver a message you're relaying, it's not only
appropriate to send a bounce but a requirement.
It's really that simple.
Sections 7.8 and 7.9 of RFC5321 do *not* suggest to drop messages. On
the contrary, your *only* alternatives are either denying the message if
you really have to, or sending a bounce in case you have accepted a
message and can not deliver it:
"6.2. Unwanted, Unsolicited, and "Attack" Messages
Utility and predictability of the Internet mail system requires that
messages that can be delivered should be delivered, regardless of any
syntax or other faults associated with those messages and regardless
of their content. If they cannot be delivered, and cannot be
rejected by the SMTP server during the SMTP transaction, they should
be "bounced" (returned with non-delivery notification messages) as
described above. In today's world, in which many SMTP server
operators have discovered that the quantity of undesirable bulk email
vastly exceeds the quantity of desired mail and in which accepting a
message may trigger additional undesirable traffic by providing
verification of the address, those principles may not be practical.
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice."[1]
Read the following sections the RFC refers to along with the above:
"7.8. Resistance to Attacks
In recent years, there has been an increase of attacks on SMTP
servers, either in conjunction with attempts to discover addresses
for sending unsolicited messages or simply to make the servers
inaccessible to others (i.e., as an application-level denial of
service attack). While the means of doing so are beyond the scope of
this Standard, rational operational behavior requires that servers be
permitted to detect such attacks and take action to defend
themselves. For example, if a server determines that a large number
of RCPT TO commands are being sent, most or all with invalid
addresses, as part of such an attack, it would be reasonable for the
server to close the connection after generating an appropriate number
of 5yz (normally 550) replies.
7.9. Scope of Operation of SMTP Servers
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. However, cooperation among sites
and installations makes the Internet possible. If sites take
excessive advantage of the right to reject traffic, the ubiquity of
email availability (one of the strengths of the Internet) will be
threatened; considerable care should be taken and balance maintained
if a site decides to be selective about the traffic it will accept
and process."[2]
What the RFC obviously means by "dropping mail without notification of
the sender" is that you do not need to *bounce* a message and that you
are allowed to instead *reject* a message.
You may also want to look at [3]:
"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. Some reasons that are not considered frivolous
are discussed in the next subsection and in Section 7.8.
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,
Klensin Standards Track [Page 71]
RFC 5321 SMTP October 2008
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification."
This clearly tells you that you *must not* drop or otherwise loose a
message once you have accepted it and that you *must* send a bounce when
the message can not be delivered.
Apparently the RFC was merely adjusted a bit to common practise
(compared to 821) in this point: Optionally denying messages has been
abused to avoid SPAM, in lack of better options. With no better options
available, 5321 now reluctantly allows you to deny messages when you
have very good reasons (like SPAM) to do so.
It does not allow you to silently drop them, and it's still true that it
is totally unacceptable to silently loose messages.
Please do configure your MTAs accordingly.
And that includes whoever runs this mailing list: When you block
messages, the senders must be informed that the delivery to the list has
failed. --- I cannot verify whether messages sent to this list have
been silently dropped. If they have, how do I make a bug report about
it? Does anyone have proof?
[1]: http://tools.ietf.org/html/rfc5321#section-6.2
[2]: http://tools.ietf.org/html/rfc5321#section-7.8
[3]: http://tools.ietf.org/html/rfc5321#section-6.1
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878ukegofj....@yun.yagibdah.de
