On Sat, Apr 01, 2000 at 12:24:43PM -0500, Patrick Bihan-Faou wrote:
> Hi,
>
> From: "Peter van Dijk" <[EMAIL PROTECTED]>
> > > advertise the e-mail address associated with that user account in the
> MAIL
> > > FROM, nothing prevents you to advertise your "official" email address in
> the
> > > reply-to header.
> >
> > Uhm. You are correct. Nothing prevents you from doing that. But it kinda
> > defeats the purpose of being able to dialin anywhere in the world, POP
> mail
> > off your home-provider and send thru the relay of the ISP you're dialing
> > into.
>
> Well I think that the better answer in this case would be to use your
> home-provider's SMTP relay using either SMTP-after-POP or SMTP AUTH or TLS
> or whatever other scheme that will let you use your *normal* relay.
That is the perfect, alas as yet utopic situation.
> Since you are already accessing you home provider's services (the POP
> account), you should be able to also its mail relay.
'should' indeed.
> 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.
Also, since we're talking about denying relaying to somebody who's actually
dialing in to your service, you already have their data (name, address), so
you can get back to them anyway. I think this policy isn worth the trouble.
> > > This amounts to enforcing stricter relay servers: should a server relay
> mail
> > > if the address presented in MAIL FROM does not belong to one of its
> domains
> > > (in addition to does it come from one of the "local" computers, etc.) ?
> >
> > Yes it should. Relaying should be based on IP, either fixed (subnets) or
> > dynamic (SMTP-after-POP), and _nothing_ else.
> >
>
> I think that this is debatable (cf. my comment above).
I hear you.
> 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.
> > Anyway, most people here will agree that the rules you are proposing are
> > insane, because you will prevent your customers from using a POP-account
> at
> > another ISP.
>
> 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.
> Please note that I am not trying to start a flame war. I just want to have
> strong arguments as to why that method should or should not be used. So far
> we have:
Ah, I appreciate this attitude :)
> - travelling users may be impacted badly by this, unless they always use
> their "home" mail relay (how feasible is it today ? should it be enforced
> ?).
Completely unfeasible. Few ISPs support SMTP-after-POP or other
remote-relay options.
> - this could work with yahoo or hotmail (because the only way you can use
> their relays is via their web interface)
Yeps, although I think it is quite feasible for a yahoo/hotmail user to
send out some mail with their hotmail/yahoo address from a dial-up, for
stuff like big attachments.
> - this is insane (this is the point I have trouble with :)
It is also my opinion ;)
Greetz, Peter.
--
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder
|
| 'C makes it easy to shoot yourself in the foot;
| C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++
