|
Re: [Asrg] A method to eliminate spam
2003-03-17 18:12:34
At 17.03.2003 13:08 -0600, meor(_at_)mail(_dot_)SoftHome(_dot_)net wrote:
>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.
What if you're a dial-in internet user?
What if there is a temporally routing problem, which makes the sender
unable to reach your mailbox-"server"?
BTW. Does "every other type network communication" that hasn't special
records for it's specific protocol make use of *static* adresses (like mail
adresses) which are independend from what FQDN the *real* destination host has?
The good thing with your "solution" is that it could fix the bad things
that came up with SMTP. But it would also "fix" the good things of it, stop
ignoring that.
>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?
Damn, yes, it really should. Say, a network administrator at AOL makes a
"little" mistake while configuring the main routers, so AOL will be
completely down for ... 10 minutes. Even in this 10 minutes *lots* of mail
*would* have been delivered to some of the millions(?) of AOL users. So
your protocol would force thousands of mail clients to retry their
delivery. If the clients were dial-in users, they wourd be forced to be
online for each retry. With a protocol that allows relay servers (like
SMTP) they can go offline and lay back without worrying what happens to
their mail. And even when the relay server is unable to deliver the mail,
it is not lost - the sender will recieve an notify when the relay server
gives up (after a reasonable period of time).
>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.
The problem is, that it has to be installed on *every* concerned client. In
a corporate environment you really want to have one central mail relay
server because it's no problem to update the filter rules for *all*
incoming and outgoing mail at this point.
[...]
>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.
AGIAN. What if TWO dial-in users want to send each other email? Both have
to be online at the same time! THIS SUCKS!!!
And you don't see how this all ever could be a problem because you become
f*cking ignorant when someone criticises your protocol.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|