At 09:53 AM 2/28/2005 -0500, you wrote:
On Mon, 28 Feb 2005, David MacQuigg wrote:
> >I haven't caught the part where you tell me why we need another thing
> >like a DSN that is not a DSN? Why not use a DSN?
>
> The DSN goes to the Return-Path, which may be forged. That is not a
> problem with most DSNs, but it is a serious problem with Bounces due to
> spam. Until now, these Bounces have been sent to the Return-Path, but
that
> practice is now becoming a problem.
So tell me again why we need those "Bounces"?
Again, a reputable Forwarder will find Bounces not an annoyance, but a
valuable statistical sample of the particular type of spam that is most
annoying to their clients (i.e. new spam sources targeting their clients
with spam clever enough to get past current blocking and filtering). Also,
users *want* the satisfaction of being able to do something about
spam. That is why you are getting all these Bounces going to forged
addresses.
As far as I can see, the
problem is sending a "Bounce" instead of a DSN. A DSN for a forged
message is trivially filtered before SMTP DATA, and aside from using a little
bandwidth, doesn't bother anyone. The "Bounces", as you note, are a HUGE
pain.
So the solution is to stop sending those stupid "Bounces" and send
DSNs like you're supposed to for delivery problems.
The solution you suggest will require educating everyone and frustrating
their desire to "send it back". The solution I'm suggesting will not
"require that we convince every mail admin to change their MTAs to
implement new extensions". A change in the Bounce address would be part of
upgrading the MTA to handle SPF checking. The people we need to convince
are at the IETF. If they set a standard for how Forwarders should affirm
their authentication results in a header, and how Receivers should generate
Bounces, mail admins will say "Great. This will make our users happy, and
provide us with an easy solution to what has been a HUGE pain."
> Such practice has never been standardized, and in fact has been vigorously
> opposed by many organizations (like SpamCop). Therefore we have no
risk of
Did you stop to wonder why SpamCop and I would oppose sending "Bounces" ?
Because they have been going to the wrong address. Do you oppose getting
Bounces for spam that actually went through your forwarding
service? Remember, these bounces will be clearly identified as such, so
you have plenty of options: 1) Ignore them. 2) Bounce them upstream. 3)
Use them to improve blocking and filtering for your clients. 4) Report them
to whatever domain-rating services you are using, and help shut down these
domains worldwide.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com