264049 - server bounce activation by user - desired, necessary, and required by security.

Status: RESOLVED DUPLICATE of bug 109930

(MailNews Core :: MIME, defect)

Description

[Don]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

       The Bounce:
    Arguments:
  Infinate bounce-
BOUNCE-ING email does NOT result in an infinate loop. This is a cop-out by
intellectually lazy argument, insinuating that not looking at the sun will
result in the sun failing to rise.  The logic is patently false.
  false sender anyway-
Immaterial argument, or straw man.  It is the last SERVER in the chain that we
wish to notify, which will bounce all the way back to any valid servers, until
we find the server carrying messages with invalid headers.  THAT server will be
hit with a sudden flash flood of bounces.  This is FINE, that's what we WANT to
do!  Force the originators of SPAM services to DEAL WITH IT.
  you can't get there from here argument-
Various 'servers do that, not clients' statements are asinine and pointless.
That's akin to saying "the sky is usually blue, today it's cloudy," and has no
other purpose.  The VERY statement is in fact "we want a client to do this." 
Answering that a client DOESN'T reflects an inability to listen.

    Reasons:
  Looping is expressly forbidden in server code. They will not continue to
resend messages infinately.  Servers without this code are a class A security
risk, as they can be deliberately 'crashed' and penetrated to allow hacker access.
  Servers that get flooded with bounce messages shut down the offending account
immediately.  If your server isn't set to do this, change it.  To fail to do so
is an open door for DDOS attacks.
  There IS NO reason why any client can't signal the server to send a bounce
message on request of the end user.  To do so merely causes the server to
communicate to the message originator that the email address is not valid.  This
is not a permanent or causal change in the ACTUAL validity of the email address.
 The only change being that the OFFENDING server will no longer send email to
that address.

    Actions:
  Create Bounce button in mail client software. GUI work. simple.
  Create bounce action in MIME code.  Not too hard seeing as the code already
exists in ALL mail servers!
  Cause Client to signal bounce action to Server.
  The HARD part: 
Servers may need a patch or update in order to ACCEPT the bounce directive from
clients!
  The IMPORTANT part:
Servers and Clients need to do this without opening security holes that allow
malicious abuse of a bounce feature to shut down email to a particular email
address widescale.  All Server patches should be tested carefully.  Client
patches aren't quite as widescale, and thus less urgent, but should be checked.

    Recommend:
  Client hook which downloads email to client host computer could use the bounce
button feature to reject messages by indicating that they were not delivered. 
Only concern is insuring that the Server doesn't then mark the Client address
off completely and reject ALL mail to that person.  Servers need only be set to
not automatically do this on a single bounce per instance or login.
  Yet, servers NEED to disconnect email addresses RECEIVING multiple bounces,
and I will guess that SENDING multiple bounces isn't such a problem.  Is this
distinguishing fact noted in Servers? From the code I've seen in "sendmail", yes
it is.

    Caveat:
  I will be willing to test drive and assist in programming of said bug/feature
request.  I am a single father however, and I can't afford to dedicate all my
time to a volunteer/unpaid position.   Actually my resume is online at
novelworlds.com as I'm seeking employment in WA.  I CAN and WILL be able to
coordinate other people who wish to tackle this issue.

  I CAN and WILL contribute code on a 'light' basis, provided there is someone
who will knock heads together with me and debug it.  I can't afford to immerse
myself while I remain unemployed - as many Americans are these days. 

tagline:
"Stocks are up, Profits are up, Unemployment is UP, don't look down." -any
economist, 1931.




Reproducible: Always
Steps to Reproduce:
1. get spam
2. be annoyed
3. slam delete key

Actual Results:  
nothing. spam is not eliminated by deleting it.

Expected Results:  
spam should be handled specially, specifically in such a way as to create
consequences for the originator.

Don Lee
US Navy programmer, cold war veteran.
Cobol, C++, Python, Assembly

www.novelworlds.com

Comment 1

[Frank Wein [:mcsmurf]]

*** This bug has been marked as a duplicate of 109930 ***