You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marc Perkel <ma...@perkel.com> on 2006/08/02 22:02:04 UTC
Allowing IMAP/POP to Send Email
Allowing IMAP/POP to Send Email
The email SMTP protocol was created in simpler times. One of the
problems is that it is far too easy for any one person to impersonate
any other person on the planet. One of the things that will reduce spam
and fraud on the Internet is to make it more difficult for one person to
impersonate someone what they aren't. But to do this we need to change
that way email is distributed and do it in a way that is a natural
evolution of the current system.
In the beginning the Internet was a Unix network where every computer
had its own SMTP server. One person would create an email that was
submitted to the local SMTP server, the local server contacted the
destination SMTP server and that server would deliver the message into
the local email box. That method still works today but few people get
their email that way.
Sender --> SMTP --> Recipient
Today we have more of a consumer model where consumers run email clients
and leave the SMTP servers to their Internet Service Providers (ISPs)
The user creates an email message that is sent to their local ISP who
has an SMTP server. That server accepts the email and then transfers the
email by SMTP to the server that stores the incoming email for that
user. Then the recipient connects to their server by POP/IMAP protocols
to download their email.
Sender --> SMTP --> Sender's ISP Server
Sender's ISP Server --> SMTP --> Recipient's ISP Server
Recipient's ISP Server --> IMAP --> Recipient
The problem is that anyone can impersonate any other person by setting
their address to be anyone else on the planet. SMTP provides no checking
to determine if the sender is the same person as they say they are. And
the end user is using the same protocols to talk to servers that servers
use to talk to each other so servers can't tell if they are talking to
legitimate servers or end users. I suggest a modification in the
IMAP/POP protocols that allow for a two way transfer of email rather
than requiring incoming email to be downloaded with IMAP/POP and
outgoing to be SMTP.
Sender --> IMAP --> Sender's ISP Server
Sender's ISP Server --> SMTP --> Recipient's ISP Server
Recipient's ISP Server --> IMAP --> Recipient
If IMAP and POP were enhanced to allow outgoing email to be transferred
back up the same connection as incoming email it would have several
advantages.
1. It would eliminate the need to configure outgoing SMTP. That makes
it easier for the consumer. It would also eliminate the need for
authenticated SMTP because IMAP/POP are already authenticated
protocols.
2. Viruses would not be able to send email because the outgoing email
connection, IMAP, will require a password to send email. The virus
won't have the password and won't be able to send.
3. The server would accept outgoing email and label the from field to
be the same as the email account preventing the user from
pretending to be an email address other than the one the user
authenticated as. It would then deliver the message to the local
SMTP server which would then send it to the destination server.
4. This method allows the system to assert that the sender's email
address was sent from a person who had the ability to log in and
read the email. Thus if you get an email from
bill.gates@microsoft.com then you know that the person sending the
email had the username and password to receive email on that account.
5. It would eliminate virus infected spam zombies from pretending to
be SMTP servers because they would no longer be the official
source of messages for domains that they pretend to be. It will be
easier to create rules that keep servers from impersonating other
servers when clients and servers use different protocols..
6. Protocols like SMTP-AUTH and Submission are no longer necessary.
It also eliminates the problem of finding an SMTP server for
outgoing email while traveling. If you can read your email under
this system, you can send email.
Re: Allowing IMAP/POP to Send Email
Posted by John Andersen <js...@pen.homeip.net>.
On Wednesday 02 August 2006 12:02, Marc Perkel wrote:
Long pedantic diatribe deleted.... (Really, don't you suppose anyone reading
this list knew all of that already)?
> 1. It would eliminate the need to configure outgoing SMTP. That makes
> it easier for the consumer. It would also eliminate the need for
> authenticated SMTP because IMAP/POP are already authenticated
> protocols.
Authenticated smtp is no harder on the user with today's MUAs than is pop.
ISPs simply took the EASY way out of setting their networks as trusted and
everybody else as un-trusted. Those that went the extra mile to get smtpauth
working are few and far between, but you can find them. I have a hosting
company which allows smtp as long as its authorized.
> 2. Viruses would not be able to send email because the outgoing email
> connection, IMAP, will require a password to send email.
And that inability would last HOW Long?
--
_____________________________________
John Andersen
Re: Allowing IMAP/POP to Send Email
Posted by Jason Haar <Ja...@trimble.co.nz>.
FYI: Courier-IMAP has had this feature for some time. You can configure
it so that any mail message dropped into an IMAP subfolder named (e.g.)
"Outbox" will be auto-sent - i.e. piped into /usr/sbin/sendmail.
Completely removes the need for SMTP.
Of course, it would really require all MUAs to be rewritten to "hide"
this technical backend skulduggery from the end-user. They should just
be able to hit "Send" as usual.
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Allowing IMAP/POP to Send Email
Posted by "John D. Hardin" <jh...@impsec.org>.
On Wed, 2 Aug 2006, jdow wrote:
> IMAP, after all, exposes user email to scrutiny on machines the
> user does not control.
Now, be fair. SMTP has exactly the same weakness. What prevents the
Earthlink SMTP servers from saving a copy of every message they
process on your behalf?
If you want your email to truly be secure and private, the ***ONLY***
way is to encrypt the body text. Anything else (e.g. privacy laws) is
merely security theatre.
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like "Oh my God, this
place is teeming with utter morons" to incorrect conclusions like
"there's nothing of value here". -- Al Petrofsky, in Y! SCOX
-----------------------------------------------------------------------
Re: Allowing IMAP/POP to Send Email
Posted by jdow <jd...@earthlink.net>.
From: "Marc Perkel" <ma...@perkel.com>
> Allowing IMAP/POP to Send Email
>
> The email SMTP protocol was created in simpler times. One of the
> problems is that it is far too easy for any one person to impersonate
> any other person on the planet. One of the things that will reduce spam
> and fraud on the Internet is to make it more difficult for one person to
> impersonate someone what they aren't. But to do this we need to change
> that way email is distributed and do it in a way that is a natural
> evolution of the current system.
>
> In the beginning the Internet was a Unix network where every computer
> had its own SMTP server. One person would create an email that was
> submitted to the local SMTP server, the local server contacted the
> destination SMTP server and that server would deliver the message into
> the local email box. That method still works today but few people get
> their email that way.
>
> Sender --> SMTP --> Recipient
>
> Today we have more of a consumer model where consumers run email clients
> and leave the SMTP servers to their Internet Service Providers (ISPs)
> The user creates an email message that is sent to their local ISP who
> has an SMTP server. That server accepts the email and then transfers the
> email by SMTP to the server that stores the incoming email for that
> user. Then the recipient connects to their server by POP/IMAP protocols
> to download their email.
>
> Sender --> SMTP --> Sender's ISP Server
> Sender's ISP Server --> SMTP --> Recipient's ISP Server
> Recipient's ISP Server --> IMAP --> Recipient
>
> The problem is that anyone can impersonate any other person by setting
> their address to be anyone else on the planet. SMTP provides no checking
> to determine if the sender is the same person as they say they are. And
> the end user is using the same protocols to talk to servers that servers
> use to talk to each other so servers can't tell if they are talking to
> legitimate servers or end users. I suggest a modification in the
> IMAP/POP protocols that allow for a two way transfer of email rather
> than requiring incoming email to be downloaded with IMAP/POP and
> outgoing to be SMTP.
>
> Sender --> IMAP --> Sender's ISP Server
> Sender's ISP Server --> SMTP --> Recipient's ISP Server
> Recipient's ISP Server --> IMAP --> Recipient
>
> If IMAP and POP were enhanced to allow outgoing email to be transferred
> back up the same connection as incoming email it would have several
> advantages.
>
> 1. It would eliminate the need to configure outgoing SMTP. That makes
> it easier for the consumer. It would also eliminate the need for
> authenticated SMTP because IMAP/POP are already authenticated
> protocols.
> 2. Viruses would not be able to send email because the outgoing email
> connection, IMAP, will require a password to send email. The virus
> won't have the password and won't be able to send.
> 3. The server would accept outgoing email and label the from field to
> be the same as the email account preventing the user from
> pretending to be an email address other than the one the user
> authenticated as. It would then deliver the message to the local
> SMTP server which would then send it to the destination server.
> 4. This method allows the system to assert that the sender's email
> address was sent from a person who had the ability to log in and
> read the email. Thus if you get an email from
> bill.gates@microsoft.com then you know that the person sending the
> email had the username and password to receive email on that account.
> 5. It would eliminate virus infected spam zombies from pretending to
> be SMTP servers because they would no longer be the official
> source of messages for domains that they pretend to be. It will be
> easier to create rules that keep servers from impersonating other
> servers when clients and servers use different protocols..
> 6. Protocols like SMTP-AUTH and Submission are no longer necessary.
> It also eliminates the problem of finding an SMTP server for
> outgoing email while traveling. If you can read your email under
> this system, you can send email.
All this blathering aside please note that SMTP-AUTH exists now. So
there is no need for POP3 send or IMAP send. Your intense concentration
on IMAP send raises sincere questions about your real motivations. IMAP,
after all, exposes user email to scrutiny on machines the user does not
control. It also severely limits the amount of storage a user can devote
to email. I prefer to use a lot of storage because I like to go back and
look for data I had at one point considered worth saving. It is easier to
store it in the email tool than to save each individual message in a
series of folders for manual access via tools not well adapted to reading
email.
You irrationally hate SMTP. Since you are approaching this project from
this biased position you are NOT serving the people you CLAIM to be
advising. It's time to admit that broaching this subject here has placed
you in the middle of a hornet's nest of opposition. Please reconsider
your position. Or else admit that this is what you were ordered to
justify by your masters so we can pressure our governments to deal with
your purported masters.
{^_^}
Re: Allowing IMAP/POP to Send Email
Posted by Logan Shaw <ls...@emitinc.com>.
On Wed, 2 Aug 2006, Marc Perkel wrote:
> 3. The server would accept outgoing email and label the from field to
> be the same as the email account preventing the user from
> pretending to be an email address other than the one the user
> authenticated as. It would then deliver the message to the local
> SMTP server which would then send it to the destination server.
> 4. This method allows the system to assert that the sender's email
> address was sent from a person who had the ability to log in and
> read the email. Thus if you get an email from
> bill.gates@microsoft.com then you know that the person sending the
> email had the username and password to receive email on that account.
I forgot to mention this in my other message, so I'll mention it now.
You don't, in fact, know that the person sending the message
had "the" username and password for that account. All you
know is that you received e-mail a server which claims to
have verified the username and password. You have no way of
knowing whether it actually did. That is, unless you have
a list of all valid e-mail servers everywhere in the world.
But if you had that, you could just ditch your whole scheme
and only accept e-mail from those servers.
- Logan
Re: Allowing IMAP/POP to Send Email
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
On Wednesday 02 August 2006 22:02, Marc Perkel took the opportunity to say:
> Allowing IMAP/POP to Send Email
>
> The email SMTP protocol was created in simpler times. One of the
> problems is that it is far too easy for any one person to impersonate
> any other person on the planet. One of the things that will reduce spam
> and fraud on the Internet is to make it more difficult for one person to
> impersonate someone what they aren't. But to do this we need to change
> that way email is distributed and do it in a way that is a natural
> evolution of the current system.
Haven't we been through this already? Switching submission protocols does
*not* make the sender address more authenticated. Cryptographic signatures
do, provided that there is infrastructure in place that allows the recipient
to bind the key that made the signature to a physical person. If you can
trust the server that handed you the mail (e.g. by help of SPF...), that
alone can ensure that the sender address is authentic, but you can't trust
servers in general.
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: Allowing IMAP/POP to Send Email
Posted by jdow <jd...@earthlink.net>.
From: "John D. Hardin" <jh...@impsec.org>
> On Wed, 2 Aug 2006, jdow wrote:
>
>> The authenticated SMTP exists now. It has password problems via
>> simple sniffing. I wish Earthlink supported SSL connections which
>> can't be sniffed.
>
> TLS?
They don't have that either.
{^_^}
Re: Allowing IMAP/POP to Send Email
Posted by "John D. Hardin" <jh...@impsec.org>.
On Wed, 2 Aug 2006, jdow wrote:
> The authenticated SMTP exists now. It has password problems via
> simple sniffing. I wish Earthlink supported SSL connections which
> can't be sniffed.
TLS?
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like "Oh my God, this
place is teeming with utter morons" to incorrect conclusions like
"there's nothing of value here". -- Al Petrofsky, in Y! SCOX
-----------------------------------------------------------------------
Re: Allowing IMAP/POP to Send Email
Posted by jdow <jd...@earthlink.net>.
From: "Logan Shaw" <ls...@emitinc.com>
> On Wed, 2 Aug 2006, Marc Perkel wrote:
>> If IMAP and POP were enhanced to allow outgoing email to be transferred back
>> up the same connection as incoming email it would have several advantages.
>>
>> 1. It would eliminate the need to configure outgoing SMTP. That makes
>> it easier for the consumer. It would also eliminate the need for
>> authenticated SMTP because IMAP/POP are already authenticated
>> protocols.
>
> But they don't already exist. Authenticated SMTP does already exist.
> So it's sort of an advantage (I really agree -- the configuration is
> a tiny bit easier), but it also has a big disadvantage that common
> e-mail clients don't have the capability to do this!
>
>> 2. Viruses would not be able to send email because the outgoing email
>> connection, IMAP, will require a password to send email. The virus
>> won't have the password and won't be able to send.
>
> Yeah, the virus won't have the password. Unless somebody comes up
> with the idea of offering a "remember my password" checkbox on the
> dialog that asks for the password. Then they will have the password.
Sniffers exist. Passwords are NOT the solution. They may evolve into
part of the problem.
Traffic analysis and slow downs for sending too many emails too
rapidly are part of the solution. Forcing authenticated SMTP submission
finishes the solution. The authenticated SMTP exists now. It has
password problems via simple sniffing. I wish Earthlink supported
SSL connections which can't be sniffed. That at least raises the
password ante a little. The slow down technology exists. Earthlink
claimed to be using it something like a decade ago. If the data
extracted from the slow down technology is used to simply shut off
accounts that are spewing, in real time, zombie spam would be materially
reduced. Automated submission of spewing addresses to Block Lists
from larger ISPs that can notice the patterns would also help everyone.
But mere passwords on unsecure protocols are no really big deal other
than it, theoretically, points to a specific machine that can be shut
down. (Since zombies share data it'll be a short time before this also
becomes mooted.)
There is no "solution" there is only measure and counter-measure as
both sides get better at what they want to do. Selling snake oil about
POP3 or IMAP email submission is just plain amateurish stupidity if it
is not driven by an ulterior motive.
{^_^}
Re: Allowing IMAP/POP to Send Email
Posted by Logan Shaw <ls...@emitinc.com>.
On Wed, 2 Aug 2006, Marc Perkel wrote:
> If IMAP and POP were enhanced to allow outgoing email to be transferred back
> up the same connection as incoming email it would have several advantages.
>
> 1. It would eliminate the need to configure outgoing SMTP. That makes
> it easier for the consumer. It would also eliminate the need for
> authenticated SMTP because IMAP/POP are already authenticated
> protocols.
But they don't already exist. Authenticated SMTP does already exist.
So it's sort of an advantage (I really agree -- the configuration is
a tiny bit easier), but it also has a big disadvantage that common
e-mail clients don't have the capability to do this!
> 2. Viruses would not be able to send email because the outgoing email
> connection, IMAP, will require a password to send email. The virus
> won't have the password and won't be able to send.
Yeah, the virus won't have the password. Unless somebody comes up
with the idea of offering a "remember my password" checkbox on the
dialog that asks for the password. Then they will have the password.
- Logan
Re: Allowing IMAP/POP to Send Email
Posted by JamesDR <ja...@trusswood.net>.
Marc Perkel wrote:
> Spam is never eliminated - just reduced. Most spam comes from virus
> infected zombies that talk SMTP. If end users were by default set up so
> that they can only send email by IMAP then you can block off SMTP ports
> for end users isolating them from the SMTP world. That would take a huge
> bite out of the spam problem.
>
>
For about a day. Spam software writers aren't stupid. All the standards
that would be necessary for this kind of system to work on a broad scale
would have to be open. By the time you got every ISP in one slice of the
world to do this, then this will be exploited. My own home ISP had this
happen to them. Bellsouth (in my area at least) blocked both 25 out and
25 in. We had to send through Bellsouth's mail server. At first it was
configured as an open relay for their customers. Then you had to
authenticate. After they enabled authentication, I haven't seen a single
Bellsouth DSL originating email spam (from the res blocks.) If others
have, chime in. But from what I see, this works. It did anger me at
first because they didn't tell their customers, and when directly asked
they denied doing such (maybe just their help desk drones didn't know.)
Anyway. Block 25, require auth to the isp's server. Done. SMTP-AUTH
would be EXACTLY the same as what you purpose. Here's an idea. Quit
waisting your time here. You haven't found any supporters here. Try
security lists. Write a letter to your ISP, your friend's ISP, your
place of business's ISP and see what they say. I bet they'll say "Not
feasible -- SMTP-AUTH works just fine"
--
Thanks,
James
Re: Allowing IMAP/POP to Send Email
Posted by Steve Thomas <li...@sthomas.net>.
> Spam is never eliminated - just reduced. Most spam comes from virus
> infected zombies that talk SMTP. If end users were by default set up so
> that they can only send email by IMAP then you can block off SMTP ports
> for end users isolating them from the SMTP world. That would take a huge
> bite out of the spam problem.
Which is something that many ISPs and corporations already do. What makes
you think that any more of them will do it if your plan were to be
implemented?
Responsible networks are already blocking port 25, while irresponsible
networks (generalizing to make a point) aren't. What's going to happen to
make the irresponsible networks change their ways? Why hasn't it happened
already? What kind of incentive does your plan specifically provide to
help change those network owners' minds?
Re: Allowing IMAP/POP to Send Email
Posted by jdow <jd...@earthlink.net>.
From: "Marc Perkel" <ma...@perkel.com>
> Logan Shaw wrote:
>> On Thu, 3 Aug 2006, Marc Perkel wrote:
>>> Not really - what I'm proposing is that the IMAP connection just pipe
>>> the message into an SMTP server. The IMAP is acting only and an
>>> authenticated connection back to SMTP. I'm not suggesting replacing
>>> SMTP. What I'm suggesting is that POP/IMAP can be used as a transport
>>> to get the mail there because it's an existing connection, is already
>>> established, is already authenticated with the credentials of the
>>> email account, and it isn't a port that people would block like port
>>> 25 is.
>>>
>>> I'm not trying to replace SMTP. I'm just trying to suggest a better
>>> way for end users to get outgoing email to the SMTP server.
>>
>> Yes. You've already said that. What you're trying to do
>> is create an internet where SMTP traffic only occurs between
>> legitimate servers. You then claim that if such an internet
>> existed, there would be a huge impact against spam. I have
>> to concur that if that were true, spam would be greatly reduced.
>>
>> Here's the problem though. We've got a logical syllogism here:
>> "If X, then Y." The "X" is "only legitimate servers speak
>> SMTP", and the "Y" is "spam will be greatly reduced".
>>
>> I agree that the "if X, then Y" part of this argument is
>> sound. The problem is, for Y to logically follow, you have
>> to establish X. A syllogism works like this:
>>
>> 1. If X, then Y.
>> 2. X is known to be true.
>> 3. Therefore, Y is true.
>>
>> Part 1 is called the major premise. Part 2 is called the
>> minor premise. Part 3 is the conclusion.
>>
>> Your argument is missing the minor premise. You have to
>> establish the minor premise or your argument will have no
>> validity.
>>
>> So then, do you wish to give up on your argument, or do you
>> wish to explain how you're going to accomplish this feat of
>> making sure that only legitimate servers try to contact other
>> servers via SMTP?
>>
>> - Logan
>>
>
> Spam is never eliminated - just reduced. Most spam comes from virus
> infected zombies that talk SMTP. If end users were by default set up so
> that they can only send email by IMAP then you can block off SMTP ports
> for end users isolating them from the SMTP world. That would take a huge
> bite out of the spam problem.
But then your network's SMTP server cannot talk to any other SMTP
server. You have to use a properly sanctioned one. THINK man. THINK.
{^_^}
Re: Allowing IMAP/POP to Send Email
Posted by Marc Perkel <ma...@perkel.com>.
Logan Shaw wrote:
> On Thu, 3 Aug 2006, Marc Perkel wrote:
>> Not really - what I'm proposing is that the IMAP connection just pipe
>> the message into an SMTP server. The IMAP is acting only and an
>> authenticated connection back to SMTP. I'm not suggesting replacing
>> SMTP. What I'm suggesting is that POP/IMAP can be used as a transport
>> to get the mail there because it's an existing connection, is already
>> established, is already authenticated with the credentials of the
>> email account, and it isn't a port that people would block like port
>> 25 is.
>>
>> I'm not trying to replace SMTP. I'm just trying to suggest a better
>> way for end users to get outgoing email to the SMTP server.
>
> Yes. You've already said that. What you're trying to do
> is create an internet where SMTP traffic only occurs between
> legitimate servers. You then claim that if such an internet
> existed, there would be a huge impact against spam. I have
> to concur that if that were true, spam would be greatly reduced.
>
> Here's the problem though. We've got a logical syllogism here:
> "If X, then Y." The "X" is "only legitimate servers speak
> SMTP", and the "Y" is "spam will be greatly reduced".
>
> I agree that the "if X, then Y" part of this argument is
> sound. The problem is, for Y to logically follow, you have
> to establish X. A syllogism works like this:
>
> 1. If X, then Y.
> 2. X is known to be true.
> 3. Therefore, Y is true.
>
> Part 1 is called the major premise. Part 2 is called the
> minor premise. Part 3 is the conclusion.
>
> Your argument is missing the minor premise. You have to
> establish the minor premise or your argument will have no
> validity.
>
> So then, do you wish to give up on your argument, or do you
> wish to explain how you're going to accomplish this feat of
> making sure that only legitimate servers try to contact other
> servers via SMTP?
>
> - Logan
>
Spam is never eliminated - just reduced. Most spam comes from virus
infected zombies that talk SMTP. If end users were by default set up so
that they can only send email by IMAP then you can block off SMTP ports
for end users isolating them from the SMTP world. That would take a huge
bite out of the spam problem.
Re: Allowing IMAP/POP to Send Email
Posted by Logan Shaw <ls...@emitinc.com>.
On Thu, 3 Aug 2006, Marc Perkel wrote:
> Not really - what I'm proposing is that the IMAP connection just pipe the
> message into an SMTP server. The IMAP is acting only and an authenticated
> connection back to SMTP. I'm not suggesting replacing SMTP. What I'm
> suggesting is that POP/IMAP can be used as a transport to get the mail there
> because it's an existing connection, is already established, is already
> authenticated with the credentials of the email account, and it isn't a port
> that people would block like port 25 is.
>
> I'm not trying to replace SMTP. I'm just trying to suggest a better way for
> end users to get outgoing email to the SMTP server.
Yes. You've already said that. What you're trying to do
is create an internet where SMTP traffic only occurs between
legitimate servers. You then claim that if such an internet
existed, there would be a huge impact against spam. I have
to concur that if that were true, spam would be greatly reduced.
Here's the problem though. We've got a logical syllogism here:
"If X, then Y." The "X" is "only legitimate servers speak
SMTP", and the "Y" is "spam will be greatly reduced".
I agree that the "if X, then Y" part of this argument is
sound. The problem is, for Y to logically follow, you have
to establish X. A syllogism works like this:
1. If X, then Y.
2. X is known to be true.
3. Therefore, Y is true.
Part 1 is called the major premise. Part 2 is called the
minor premise. Part 3 is the conclusion.
Your argument is missing the minor premise. You have to
establish the minor premise or your argument will have no
validity.
So then, do you wish to give up on your argument, or do you
wish to explain how you're going to accomplish this feat of
making sure that only legitimate servers try to contact other
servers via SMTP?
- Logan
Re: Allowing IMAP/POP to Send Email
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
On Thursday 03 August 2006 19:25, Marc Perkel took the opportunity to say:
> Chris Lear wrote:
> > What if I set up an SMTP server at home behind my ADSL router, collect
> > my vanity-domain mail there, and access it via IMAP or POP3? It seems
> > I only have one option, which is to send my mail via IMAP to my home
> > server. Which then sends via SMTP to... the Internet (or via a
> > smarthost). And the home server sending via SMTP is going to look a
> > bit like a MUA sending via SMTP. How would you tell the difference? Is
> > a home mail server outlawed in the brave new world? Or does my SMTP
> > server have to learn to talk IMAP to make message submissions to the
> > ISP's server?
> >
> Then it would be a server and talk SMTP. Servers still talk SMTP. I have
> a home SMTP server myself.
Ooookaaay... but they have to use SMTP AUTH, right? So why can't MUAs talk
SMTP as well then? The only reason you have left is that you want to remove
existing functionality (SMTP) from MUAs and replace it with something (two
things, even) that doesn't yet exist (mail submission over POP and IMAP).
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: Allowing IMAP/POP to Send Email
Posted by jdow <jd...@earthlink.net>.
From: "Marc Perkel" <ma...@perkel.com>
>
> Chris Lear wrote:
>>
>>
>> What if I set up an SMTP server at home behind my ADSL router, collect
>> my vanity-domain mail there, and access it via IMAP or POP3? It seems
>> I only have one option, which is to send my mail via IMAP to my home
>> server. Which then sends via SMTP to... the Internet (or via a
>> smarthost). And the home server sending via SMTP is going to look a
>> bit like a MUA sending via SMTP. How would you tell the difference? Is
>> a home mail server outlawed in the brave new world? Or does my SMTP
>> server have to learn to talk IMAP to make message submissions to the
>> ISP's server?
>>
>> Chris
>>
>
> Then it would be a server and talk SMTP. Servers still talk SMTP. I have
> a home SMTP server myself.
Yoohoo, Marc! What is the difference between a home SMTP server YOU
run and one that is included in malware that has turned your machine
into a Zombie?
It your specific network arrangement is to be supported then you are
allowing port 25 connections between your server and others. Thus you
have done absolutely nothing to reduce spam. You've only cost people
money changing their entire mail setups end to end.
{^_^}
Re: Allowing IMAP/POP to Send Email
Posted by Marc Perkel <ma...@perkel.com>.
Chris Lear wrote:
>
>
> What if I set up an SMTP server at home behind my ADSL router, collect
> my vanity-domain mail there, and access it via IMAP or POP3? It seems
> I only have one option, which is to send my mail via IMAP to my home
> server. Which then sends via SMTP to... the Internet (or via a
> smarthost). And the home server sending via SMTP is going to look a
> bit like a MUA sending via SMTP. How would you tell the difference? Is
> a home mail server outlawed in the brave new world? Or does my SMTP
> server have to learn to talk IMAP to make message submissions to the
> ISP's server?
>
> Chris
>
Then it would be a server and talk SMTP. Servers still talk SMTP. I have
a home SMTP server myself.
Re: Allowing IMAP/POP to Send Email
Posted by Chris Lear <ch...@laculine.com>.
* Marc Perkel wrote (03/08/06 14:39):
>
> Tony Finch wrote:
>> The reason that message submission is done with SMTP is because of the
>> number of SMTP extensions that the MUA will want to use, in particular
>> DSNs, deliver-by, deliver-after, message tracking, and whatever else may
>> be invented in the future. If you want to make message submission a part
>> of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
>> which is a colossal waste of time.
>>
>>
>>
>
> Not really - what I'm proposing is that the IMAP connection just pipe
> the message into an SMTP server. The IMAP is acting only and an
> authenticated connection back to SMTP. I'm not suggesting replacing
> SMTP. What I'm suggesting is that POP/IMAP can be used as a transport to
> get the mail there because it's an existing connection, is already
> established, is already authenticated with the credentials of the email
> account, and it isn't a port that people would block like port 25 is.
>
> I'm not trying to replace SMTP. I'm just trying to suggest a better way
> for end users to get outgoing email to the SMTP server.
>
What if I set up an SMTP server at home behind my ADSL router, collect
my vanity-domain mail there, and access it via IMAP or POP3? It seems I
only have one option, which is to send my mail via IMAP to my home
server. Which then sends via SMTP to... the Internet (or via a
smarthost). And the home server sending via SMTP is going to look a bit
like a MUA sending via SMTP. How would you tell the difference? Is a
home mail server outlawed in the brave new world? Or does my SMTP server
have to learn to talk IMAP to make message submissions to the ISP's server?
Chris
Re: Allowing IMAP/POP to Send Email
Posted by Marc Perkel <ma...@perkel.com>.
Tony Finch wrote:
> The reason that message submission is done with SMTP is because of the
> number of SMTP extensions that the MUA will want to use, in particular
> DSNs, deliver-by, deliver-after, message tracking, and whatever else may
> be invented in the future. If you want to make message submission a part
> of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
> which is a colossal waste of time.
>
>
>
Not really - what I'm proposing is that the IMAP connection just pipe
the message into an SMTP server. The IMAP is acting only and an
authenticated connection back to SMTP. I'm not suggesting replacing
SMTP. What I'm suggesting is that POP/IMAP can be used as a transport to
get the mail there because it's an existing connection, is already
established, is already authenticated with the credentials of the email
account, and it isn't a port that people would block like port 25 is.
I'm not trying to replace SMTP. I'm just trying to suggest a better way
for end users to get outgoing email to the SMTP server.
Re: Allowing IMAP/POP to Send Email
Posted by Tony Finch <do...@dotat.at>.
The reason that message submission is done with SMTP is because of the
number of SMTP extensions that the MUA will want to use, in particular
DSNs, deliver-by, deliver-after, message tracking, and whatever else may
be invented in the future. If you want to make message submission a part
of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
which is a colossal waste of time.
On Wed, 2 Aug 2006, Marc Perkel wrote:
> 2. Viruses would not be able to send email because the outgoing email
> connection, IMAP, will require a password to send email. The virus
> won't have the password and won't be able to send.
Not true. The virus controls the machine so it can obtain the user's
password. In any case, and as many people have already pointed out, you
can authenticate SMTP as well as you can IMAP.
> 4. This method allows the system to assert that the sender's email
> address was sent from a person who had the ability to log in and
> read the email.
Also true for authenticated SMTP.
> 5. It would eliminate virus infected spam zombies from pretending to
> be SMTP servers because they would no longer be the official
> source of messages for domains that they pretend to be.
It would not. They could still talk SMTP or steal users' login
credentials.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.