One of the problems with SMTP in my opinion is that it allows end users
to talk on port 25 to servers and therefore can't be distinguished from
server to server traffic.
Imagine a policy where ISPs blocked port 25 for consumers by default and
forced them to talk to mail servers on port 587 to
The consumer (Dialup,DSL,Cable, Wireless broadband,etc) internet is
slowly moving to this, with one minor exception:
Marc Perkel wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish cons
Forrest W. Christian wrote:
The consumer (Dialup,DSL,Cable, Wireless broadband,etc) internet is
slowly moving to this, with one minor exception:
Marc Perkel wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a s
The problem with that idea: it relies on ISP's distinguishing end users and
mail servers. Some ISPs are known to make a distinction on price (i.e. they
would charge much more for full access than not) or - as previous discussions
have shown -
do not even distinguish static ip and dynamic ip custo
Forrest W. Christian wrote:
The consumer (Dialup,DSL,Cable, Wireless broadband,etc) internet is
slowly moving to this, with one minor exception:
Marc Perkel wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a s
At 06:11 16-07-2007, Marc Perkel wrote:
Imagine a policy where ISPs blocked port 25 for consumers by default
and forced them to talk to mail servers on port 587 to send SMTP.
Suppose that all SMTP servers who took email from consumers had port
587 open as well as port 25.
Some ISPs already do
On 7/16/07, John Rudd <[EMAIL PROTECTED]> wrote:
You can get this same effect without caring about the port number. Just
require SMTP-AUTH for relaying. This is easily achieved, you just
remove any hosts you don't directly control from your relay domain(s).
That means your clients (no matter wh
Am/On Mon, 16 Jul 2007 06:11:32 -0700 schrieb/wrote Marc Perkel:
>One of the problems with SMTP in my opinion is that it allows end users
>to talk on port 25 to servers and therefore can't be distinguished from
>server to server traffic.
>
>Imagine a policy where ISPs blocked port 25 for consume
Matthias Schmidt [c] wrote:
Am/On Mon, 16 Jul 2007 06:11:32 -0700 schrieb/wrote Marc Perkel:
One of the problems with SMTP in my opinion is that it allows end users
to talk on port 25 to servers and therefore can't be distinguished from
server to server traffic.
Imagine a policy where ISP
Am/On Mon, 16 Jul 2007 09:02:58 -0500 schrieb/wrote Richard Frovarp:
>Matthias Schmidt [c] wrote:
>> Am/On Mon, 16 Jul 2007 06:11:32 -0700 schrieb/wrote Marc Perkel:
>>
>>
>>> One of the problems with SMTP in my opinion is that it allows end users
>>> to talk on port 25 to servers and therefor
On 7/16/07, Matthias Schmidt [c] <[EMAIL PROTECTED]> wrote:
I know that .
I just meant it's not possible in the real world to prevent "clients"
from talking to port 25 (of course as long as it is not closed by some
isp) or to distinguish a mail-bot from a real server just through the
port the
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I think this kind of
configuration could be used to help isolate virus infected computers
Jari Fredriksson wrote:
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I think this kind of
configuration could be used to help isola
Jari Fredriksson wrote:
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I think this kind of
configuration could be used to help isolate
Marc Perkel wrote:
Jari Fredriksson wrote:
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I think this kind of
configuration could b
John Rudd wrote:
Marc Perkel wrote:
Jari Fredriksson wrote:
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I think this kind of
c
Richard Frovarp wrote:
You could just as well lock down 25 on your outgoing and call it good.
Only problem is 25 is blocked at the edge of some networks and you users
won't be able to send to you. There is nothing inherently more secure
about using the submission port.
The things being di
Marc Perkel wrote:
John Rudd wrote:
Marc Perkel wrote:
Jari Fredriksson wrote:
[EMAIL PROTECTED] wrote:
If port 25 were blocked from consumers and they were forced to talk to
servers on port 587, even without authentication, then a server could
distinguish consumers from other servers. I
Port 587 is the mail submission port. That port should accept mail
only after SMTP AUTH, no matter whether the submitter is on "my
networks" or roaming. What's the point of accepting unauthenticatd
sumbission on port 587 (or any port)?
Port 25 is the mail relay port (no authentication for M
>
> What stops your customers from submitting to port 25 on your port 25
> machines, when they're out roaming (ie. not on an IP address from which
> you have blocked port 25 traffic)?
>
> That's part of what I was saying. Simply segregating which IPs are
> blocked for port 25 isn't going to he
Robert - eLists wrote:
What stops your customers from submitting to port 25 on your port 25
machines, when they're out roaming (ie. not on an IP address from which
you have blocked port 25 traffic)?
What stops them from submitting on port 25 is admin-ing it so that "no smtp
auth" is availabl
John Rudd wrote:
> things on the anti-virus side ... especially once virus authors figure
> out how to extract passwords from locally installed mail clients.
Already exists, however the most recent instance we saw was most likely
injecting messages into OE's outbox instead of using locally store
Robert - eLists wrote:
John
What stops them from submitting on port 25 is admin-ing it so that "no smtp
auth" is available on port 25
And, isn't port 465 designated for ssl and smtp auth ?
- rh
465 is SSL, but it isn't the port you should be using. Do TLS via 587 or
25. I can't
>
>
> That wont stop them from submitting on port 25. That will stop them
> from relaying through port 25. So this wont "isolate viruses", as the
> virus can still run rampant through your own user base.
>
> Really. This isn't an anti-virus solution. It's an anti-relaying
> solution.
John
John Rudd wrote:
Robert - eLists wrote:
What stops your customers from submitting to port 25 on your port 25
machines, when they're out roaming (ie. not on an IP address from which
you have blocked port 25 traffic)?
What stops them from submitting on port 25 is admin-ing it so that
"no s
Marc Perkel wrote:
This would isolate
viruses and if you can create some significant isolation then the bot
armies die out. Viruses is something that can be beaten.
And as people have been pointing out to you, this wont defeat the viruses.
1) Some viruses already know they can put their o
John Rudd wrote:
1) Some viruses already know they can put their outbound messages into
the Outlook outbound folder.
2) Viruses can/will adapt by figuring out how to leverage stored
SMTP-AUTH configurations. They can probably pick 3 or 4 implementations
to target (Outlook, Thunderbird, Mail,
Marc Perkel wrote:
The idea is that you would close port 25 to consumers as part of the
solution. Actually ideally all cable modems and DSL modems should
provide NAT and have port 25 closed by default. But it should be
settable so people who are sharp can turn off the blocking. But you
have
28 matches
Mail list logo
