Re: [Asrg] A method to eliminate spam

meor(_at_)mail(_dot_)SoftHome(_dot_)net wrote:
>  >Every mail client would have to become a full mail server with MX'ing, 
> queuing and the rest of the 9 yards.  Sending an email to large numbers 
> of recipients (especially mailing lists) would become extremely unreliable.
> I believe these problems are a large result of comparing this technique 
> to how E-Mail is currently handled right now.  Every sending client 
> would not have to become a mail server.  The sending clients could use 
> normal A-record lookups to resolve DNS names instead of using MX 
> records.
Why on earth would you want to abandon MXes?  MXes serve an extremely 
useful purpose even if your "solution" was adopted - failover, 
prioritization, enabling systems not on the Internet to receive email 
(hint: my home machine doesn't have, and has no need for, an A record. 
Couldn't use one even if it had one.  It's not Internet-connected.).
There's also the issue of having to expose internal email topology (eg: 
which machine holds my mailbox?  You can't tell.  We don't want you to 
be able to tell.  We don't want anyone to be able to connect to it 
directly at _all_.)
> The sending client would not have to implement server queues 
> as it would only be sending mail from one user.
When faced with the option of not being able to hit send unless the 
recipient's mailbox machine was currently online, sending clients would 
have to. Dealing with sporadic machine outages would make mailing lists 
(or even modest receiver lists) extremely unpleasant to operate if you 
couldn't queue.  Imagine the world-wide grief if a backhoe took out 
AOL's connectivity for a short time, or an individual mailbox server 
went down.  My home machine would never get another email again...
> >There goes any chance for rate limiting, send filtering, or even 
> >logging (especially in a corporate environment).
> I don't see how rate limiting would be affected with this method, I 
> would like to know exactly what you mean by this.
How would ISP (or a corporation) block outbound mailbombs and the like 
if they don't get to see the traffic?  Legal liabilities galore.
> Send filtering and 
> logging however are different topics, both of these are easy to get 
> around by any knowledgeable computer user.
Huh?  I'd like to see any of our users get around our send filtering and 
logging.  Hint: we block direct outbound email simply by denying 
outbound port 25.  As do many ISPs with dialup pool router blocks. Short 
of active collusion with outside entities (eg: port forwarding ala open 
proxies) they can't.
> Could you give some examples 
> of how send filtering and logging are beneficial to corporations?
Blocking outbound klez.  I wish Verizon would do that...
Logging all email is becoming a legal necessity these days [Patriot Act 
plus others, mutter].
> Is 
> this logging any different than just normal usage logging that 
> administrators perform?  Logging like to see what users are doing with 
> HTTP, FTP, messaging systems, etc.  Could logging programs not be 
> adapted, if people wanted to, to log new protocols like this one?
Yeah, by implementing proxies as they do for HTTP and FTP.  Which 
defeats your proposal because they're nothing more than intermediate 
mail servers.  Packet logging is impractical or useless - it shows 
nothing of the details of the email, such as recipient address.
>  >Legitimate bulk mailing would become excrutiatingly painful.
> Well, right now legitimate bulk mailing is kind of broken.  In order for 
> myself to sign up to this list I had to send and receive 3 pieces of 
> E-Mail.  In the overview I did address bulk mailing.  If a bulk mailer 
> is on a white list of someone(legitimate), then the bulk mailer does not 
> have to use any CPU time to send the message, it is allowed to be sent 
> as simply as it is right now.
So now we have two email protocols, one for bulk and one for non-bulk. Ouch.

> I don't see how this is true.  I believe this method is a more robust 
> method opposed to simple E-Mail system we use right now.  As such it 
> requires slightly different methods, but even the current E-Mail system 
> has it's own methods to get used to.  Different is not the same as worse.
Requiring the recipient mailbox machine to be online and operational at 
the time of sending a piece of email is, by itself, considerably worse 
than the status quo.  Race conditions. Etc. Vastly more unreliable.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg