--On Montag, Juli 12, 2004 16:32:00 +0300 "Andrew G. Tereschenko"
<spf-discuss(_at_)spam(_dot_)24(_dot_)odessa(_dot_)ua> wrote:
[...]
I've send this repro steps to Chris 11 hours ago.
Since there was no follow-up I think that community will benefit.
I've modified original messsage to him only a few.
[...]
EHLO Fast_Speed_DSL
MAIL FROM: <Troyaned_user(_at_)attacker(_dot_)com>
RCPT TO: <tag(_at_)xxxxxx(_dot_)ua>
DATA
From: <Troyaned_user(_at_)attacker(_dot_)com>
Delivery-Notification-To: <christopher(_at_)pobox(_dot_)com>
OK, the spammer requests an MDN.
Disposition-Notification-To: <christopher(_at_)pobox(_dot_)com>
This is not a valid header. DSN always have to be sent to the envelope
sender according to RFC3464:
| The DSN MUST be addressed (in both the message header and the
| transport envelope) to the return address from the transport envelope
| which accompanied the original message for which the DSN was
| generated. (For a message that arrived via SMTP, the envelope return
| address appears in the MAIL FROM command.)
Message-ID: Enlarge_Your_Call_Us_At_8_800_123456789
Sender: Troyaned_user(_at_)attacker(_dot_)com
Subject: Enlarge it. Read more on
http://cheap.domain.we.buy.using.stolen.creditcard.com
<empty message>
.
QUIT
--
The SMTP server will validate if IP used by zombie valid for
Troyaned_user(_at_)attacker(_dot_)com and will issue "SPF: pass" result.
But no checks performed on christopher(_at_)pobox(_dot_)com email address.
OK, but AFAICS there is no need to verify that address.
After message delivered - christopher(_at_)pobox(_dot_)com you will recieve
something
like this immedaitely.
(I've checked this on real-server, in addition to threoretical knowleage
I've)
That server seems to be broken. The DSN should have been sent to to the
envelope sender, <Troyaned_user(_at_)attacker(_dot_)com>. This way DSNs are no
problem as the spammer can trigger only DSNs to domains that he
controls.
[...]
And a few time after this - read-reciept can arrive to Chris if
tag(_at_)xxxxxx(_dot_)ua will decide to click "Yes" then opened message.
So ?
So apparently tag(_at_)xxxxxx(_dot_)ua decided to send an MDN to
christopher(_at_)pobox(_dot_)com (I just hope that you chose that address well
and
did not burn a real customer's address). Although honestly I do not know
anybody who is willing to accept that kind of invasion of privacy, all
of my correspondents reject MDN requests.
[...]
Do SPF prevent email christopher(_at_)pobox(_dot_)com from appering in
Delivery-Notification-To header if xxxxxx.ua will perform SFP checks ?
There is no such header in the RFCs. DSN addressing is based only on
envelope information and this *is* checked by SPF. So SPF protects you
from this kind of unsolicited DSNs.
Or you propose is to disable all delivery notifications and bounces ?
I disable MDNs on all installations as part of our privacy policy. If
the user wants to change this default he is responsible for the results
(and will be held accountable for any unsolicited MDNs he sends as the
MUAs that I know show whom they are sending the MDN to).
What's wrong with xxxxxx.ua server on your opinion ?
It sends DSNs to the wrong address. What software are you running on
that server?
Do you wanna leave spammers such an easy way to hide
Are you aware that not only Delivery-Notification-To will generate
automatic messages by mail servers ?
If spammer will contact secondary MX first, but user does not exists on
primary MX,
or mailbox quota reached, or primary MX will never come-up online or a few
others reasons.
Anything from above will result bounces with short text from spammer
delivered to innocent christopher(_at_)pobox(_dot_)com email address.
All those are DSN and thus go to the spammer. Also the secondary MX
should check for valid users if possible (e.g. by using LDAP) and reject
invalid recipients instead of generating DSNs.
P.S> If somebody feel non-comfortable that I've started too many threads
and asked a lot of questions - let me know and I will unsubscribe.
If we were unwilling to answer these questions, how could we expect
people to use SPF? This way we can eliminate shortcomings or at least
point them out to prospective users (like the security risk with regard
to split horizon DNS) so they know exactly what they are getting into
when they use SPF.
Ralf Döblitz