[PLUG-TALK] Bounced emails

[wes]

On Fri, Jan 15, 2010 at 6:09 PM, Denis Heidtmann
<denis.heidtmann at gmail.com>wrote:

> On Fri, Jan 15, 2010 at 5:45 PM, wes <plug at the-wes.com> wrote:
> >
> >> Questions:
> >> Why do some servers refuse to comply with 2505?
> >
> > There's something called address spoofing, where spammers use your
> address
> > as the "From:" address in spams they send out. This causes a deluge of
> > bounce messages to be sent to you, resulting from emails you never sent.
> > This practice prevents that backlash.
> >
> >>
> >> Why do some providers require compliance, while others do not (gmail,
> >> for example)?
> >
> > Why should there be uniformity? Every mail server admin has the choice of
> > how their mail server works. Sometimes this freedom causes some things to
> > not work.
> >
> >>
> >> Is it reasonable for dslnorthwest to require compliance?
> >
> > That is a tough question. I'm sure the staff at DSLNorthWest discussed
> the
> > matter and decided it would be preferable to enforce the rules. Their
> > reasons are their own; their freedom is our freedom. I'm sure if enough
> of
> > their customers complained about this, they would change this practice.
> >
> > -wes
> >
> My understanding of the motivation for rfc 2505 is SPAM reduction. Are
> you saying that uniform compliance would not improve the situation?
>
>
Correct, it's not something that really helps or hurts the spam situatoin.



> With regard to bounces: My sister-in-law (let's say sil at foo.com) sends
> a message to me.  dslnorthwest refuses it because her server does not
> accept any connections.  So she gets the bounce message.  If a spammer
> spoofs her address and the spammer's server also does not accept any
> connections, who gets the bounce message?  Does it not come back to
> sil at foo.com?  Or does it go into a black hole?
>
> -Denis
>


Black hole.

-wes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pdxlinux.org/pipermail/plug-talk/attachments/20100115/02eb0391/attachment.html>