I guess it's time to close the debate on that issue.

I appreciate the main point here which is: that solution could work, except
that today it is not practical to use "remote" relays that correspond to
your main email domain.


----- Original Message -----
From: "Peter van Dijk" <[EMAIL PROTECTED]>
> On Sat, Apr 01, 2000 at 12:24:43PM -0500, Patrick Bihan-Faou wrote:
> > Again I am not saying that this is practical today. My only claim is
that
> > you should be able to use the domain indicated in MAIL FROM to do
validity
> > checks and possibly reject spam.
>
> ágain 'should'. But you can't enforce this policy until all providers in
> the world support this.

[...]

> > If I am an ISP, why should I let somebody use my mail servers to relay
> > messages that pretend they are not from one of my users (including any
> > virtual domains that I may have) ?
>
> Becuase the person in question is dialling in to _your_ service, and you
> are probably making money out of that. They're paying. You provide a
> service. The picture is very simple.

This is the key point. Personally, I view a provider's task as giving me
access to the internet (a pipe). The rest (SMTP relays, etc.) is secondary
and I would not mind if the provider told me to use my primary servers for
that. Of course you would have now 2 classes of users: internet connection
and internet connection + services.

I guess that this way of looking at a provider is still a bit new, but
ultimately I think that we will have to move in that direction. There
certainly aren't many technological barriers anymore to do that.


> > When you configure a POP account in your MUA, you usually configure a
SMTP
> > server along with it. Why not configure that ISP's SMTP server ?
>
> Becuase that ISP is not so stupid as to allow you to relay while you're
not
> dialling in to them.

This is the other part of the problem. If I pay somebody to handle my mail,
I expect that he will provide me with a way to do it all the time. We now
have the technology to do it (ranging from SMTP over TLS, SMTP after POP,
tunneling, etc.). I hope that providers will start using them sometime.


Anyway, this is now of topic as far as qmail goes, we agree that we can't do
that now, so let's close the subject.


Patrick.



Reply via email to