--On Dienstag, Juli 13, 2004 23:02:55 +0300 "Andrew G. Tereschenko"
<spf-discuss(_at_)spam(_dot_)24(_dot_)odessa(_dot_)ua> wrote:
----- Original Message -----
[Ralf Doeblitz]
OK, the spammer requests an MDN.
> Disposition-Notification-To: <christopher(_at_)xxxxx(_dot_)com>
This is not a valid header. DSN always have to be sent to the envelope
sender according to RFC3464:
How about VERP?
Variable Envelope Return Path - the stress is on the second word, this
technique modifies the envelope sender.
I would like to collect not only bounces - but also delivery receipts
automatically.
Even more - I would like two different VERP addresses used for server
delivery and actual user read.
DSNs (and thus VERP) are for delivery only (it is *Delivery* Status
Notification). For user confirmation of reading (or disposal), you must
use MDN, which uses a specific address given in the request.
So example I would like to know if user or at least his mail server
received my invoice with "net 5 days payment terms".
I want to know it was not lost or delayed in transit.
Use a DSN with "return on success,delay,failure" options set.
I do not want user to compose confirmation emails manually (think about
his per-hour rate and timesaving ;o) - use software for this purpose.
Well, I usually confirm manually as many mails require an answer anyway
(even if it is only a "I'm swamped with work, will process this next
week/month/year" note).
Also I would like software allow me to do all this, while preventing
abuse.
For example AOL SMTP outgoing server must not allow specify DSN on mailbox
of another AOL user (but aliases of current user is ok).
SPF does that as far as possible already. DSNs go to the envelope
sender, and this is the identity that we check.
Validation must be performed (just like current virus scan), and forged
email blocked early.
But if user decided to put notification/reply-to addresses using domain he
own (other that @aol.com - for example @jondoe.com),
SPF must transform in Reply-To Permitted From and DSN Permitted From.
No. DSNs *always* use envelope sender, so there is no need for
additional checks.
So apparently tag(_at_)xxxxxx(_dot_)ua decided to send an MDN to
christopher(_at_)xxxxx(_dot_)com (I just hope that you chose that address well
and
did not burn a real customer's address). .
SFP validate From:/Sender: email to belong to real sender.
Why do you expect all others valuable email addresses validated manually
by user?
When I respond to mails I check which address they are going to be
delivered to. It may be just a habit, but many of my correspondents can
be reached either at work or at home and I usually try to select the
address that is more approriate to the time of day, subject and urgency
of the mail.
(BTW, How? I do not see email address I will send MDN. My extremely
popular Outlook Express shows me simply "Yes/No")
Urgh. Borken crapware strikes again. But I assume that Microsoft will
fix this omission when the deploy Sender ID. It should be added to the
draft if it is not already in there (display address that MDNs will be
sent to, verify this address and display that status too).
BTW: Mulberry shows the address when it asks whether I want the MDN to
be sent.
How it this different from current situation I can analyze "Received: "
headers to check "From:" are legit?
In no way. If your user agent does not help you, you will have to do the
check on your own. If you know the sender (and you know that From: has
been verified by Sender ID), you might recognize the target address.
I would like to obtain as much as possible information automatically.
Of course. Checking each identity and displaying whether it has been
verified is a nice thing to have.
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
As for privacy - it's for individuals. Not for business.
Even more important. I do not want everybody to know when I have read
their mail (not only IF, but specifcally WHEN). This can disclose quite
a lot of information about your living habits.
You cannot ignore USPS mail letter with court order and ask postman to not
send delivery or non-delivery receipts ;-)
This would be an analogue to DSNs. I have no problems with DSNs as they
do not invade my private life (no disclosure of my actions, just a
verification that a machine acted upon the mail without any human being
interfering).
I do not want email software cropped simply because you cannot prevent
abuse.
Instead if removing useful features - add abuse prevention.
If you will remove features currently described in specification - this
result people to reinvent wheel.
No, I just want the user to have controls over his systems. MDNs are
fine *if* the user decides that he wants to send them (by confirming
with a click or keypress).
Ralf Döblitz