Daniel Feenberg wrote:
On Sun, 14 Dec 2003, Philip Miller wrote:
I don't trust my ISP to get it right with regard to their mail server. They
have some large number of MTAs which make outbound connections, and 1 or 2
of them are blacklisted. Because of stupid policies enforced by other
providers (AOL), I already cannot connect out directly, so I am forced to
forward my mail through smtp.comcast.net. This means I have a choice between
not reaching certain ASRG members whose servers use RBL or not reaching
friends and family on AOL. I'm not going to reconfigure a mailserver used by
multiple people every time I want to send a message to AOL or ASRG.
About virtual hosts: I am a student. I am a minor. I do not have ready
access to a credit card to pay for such service. Whatever I can't get for
free online, I can't get at a "ridiculously cheap" cost. I happen to have
broadband access, and I run a server of my own, for utility and education.
If I were forcibly prevented from using it, I would not be happy, and I'm
sure many others are in a situation similar to this.
It is important that "consent" include "consent of the sending AS"
expressed somehow. It could be lifting a block on port 25, or some
mechanism enforced only at the receipient end. But anything suggesting
that the origin AS should not have to provide consent for sending to port
25 is to create a right to spam which will be exceedingly difficult to
counter.
The current situation is that very few ISP even bother to block owned
machines. Surely that can't be BCP. BCP must be to forward port 25 packets
only for customers who have asked for such service. This is necessary to
protect address blocks (other customers) from loss of service.
BCP would be carefully monitoring their network, and blocking any customers
whose traffic signatures indicate that they've been '0wned' or infected.
Failing that, it would be perfectly fine for them to block all potentially
harmful traffic and allow it out upon customer request and possible
acceptance of accountability.
However, they will do neither, because to do so would not be compatible with
their business model. It costs them money to do anything more than block
SMTP out universally or mark it all in DUL/MTA-Mark/whatever, and they don't
want to spend that money. Most consumer ISPs are the same way, and some of
us don't have an alternative.
Should Comcast enforce a block on port 25, and charge unreasonably for
unblocking it, then users of Comcast should explore using other MTAs. I
notice that smtp.com is already in the business of providing smtp relays,
and should a large operator like Comcast create a larger need, there would
no doubt be other players.
How would an smtp.com relay help me if port 25 were blocked? My MUA wouldn't
be able to connect to it either, unless they use SUBMIT, which is still
exceedingly rare.
As a practical matter, indivduals using sendmail can use the mailertable
feature to direct messages directly to the remote MTA, but fall back to
a specified relay MTA should their access to the remote MTA be blocked
(for example, by receivers that reject mail apparent dial-up lines).
This is not unique to sendmail. As I said earlier, I run postfix, and all of
my outgoing mail is relayed through smtp.comcast.net. However, If we were to
push LMAP, I certainly would NOT want to authorize smtp.comcast.net to send
for zemos.net, because that would allow any comcast customer to send as
zemos.net, a very undesireable idea.
These proposals go hand in hand, but there are some kinks to work out.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg