Re: [Asrg] A method to eliminate spam

>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 are other methods of fail safe and redundancy besides MX 
records.  Every other type of network communication that needs 24/7 up 
time, but does not make use of MX records has ways of keeping up time 
despite machines failing.  Every other type of network communication does 
not have special records for it's specific protocol, yet people are still 
able to full up time.
I don't know the personal situation with your machine at home but I don't 
see how it is able to send/receive mail if it isn't connected to the 
Internet ever.  I also may be naive but I don't see a resounding reason to 
have a mail server that is not connected to the network which it is 
receiving mail from.
>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...
If a backhoe took out AOL's connectivity, there are going to be more issues 
at stake than just this method.  If no one can connect to AOL's servers AOL 
itself will be down.  None of it's users will be able to use it's services, 
no one will be able to get to it's web page, nothing.
Maybe I overlooked it, but do you believe that this method should protect 
against catastrophic failures of this kind?

>How would ISP (or a corporation) block outbound mailbombs and the like if 
they don't get to see the traffic?  Legal liabilities galore.
Unless you're mail bombing someone who has white listed you(someone who 
trusts you), your mail bomb isn't going to be able to nearly as effective 
as they are right now.  I also don't see why a filter could not be 
developed for this protocol as well.  Just because it isn't SMTP, doesn't 
mean it cannot be monitored by administrators.
>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.
Yes, I was implying outside assistance.


>Blocking outbound klez.  I wish Verizon would do that...
Logging all email is becoming a legal necessity these days [Patriot Act 
plus others, mutter].
Again, I don't see how a filter could not be developed for this protocol if 
one was so desired.

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.
I think packet logging is useful.  If you monitor communications between 
the client and the destination mail host, how could you not reconstruct who 
it was to, who it was from, what public keys were exchanged, etc?  In the 
case of mail bombing it would be very obvious if someone is opening several 
hundred communications with the destination mail box(public key) within a 
short period of time.  I would say this method would actually help you 
because you _can_ find the recipient address.

>So now we have two email protocols, one for bulk and one for non-bulk. Ouch.

No, there are no two protocols.  White listing is built in to the 
protocol.  It is the basis for fast mail sending.  Trusted users do not 
have to compute a cipher key every time they send mail, only if you are not 
on the white list.  White lists can be tied to address books and sending 
mail.  There are not two protocols for this, this was outlined in the overview.

>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.
I don't see how the mail server being off-line is worse than any other 
server going off-line that needs 24/7 up time.  If your web server goes 
down and you have no redundancy, you have a problem.  If your Internet 
router box goes down and you have no redundancy, you have a problem.  I 
believe this method succumbs to the same issues as every other network service.
The difference with this method opposed to the current E-Mail system is 
that you are not wasting gigabytes worth of bandwidth and disk space 
transferring and storing unsolicited junk mail because no one can make 
money off of sending it anymore.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg