Authentication for outgoing TCP/IP Services mail?
Paul Sture
authentication for outgoing mail (Good Move against spamming zombies).
In Mac Mail, Thunderbird etc, there are settings for supplying
authentication for outgoing mail.
Does similar exist in TCP/IP Services for VMS?
--
Paul Sture
Q. Where did the names “C” and “C++” come from?
A. They were grades. —Jerry Leichter
JF Mezei
>
> Some time ago, my ISP changed their mail system so that I need to supply
> authentication for outgoing mail
> Does similar exist in TCP/IP Services for VMS?
*NO*.
The VMS SMTP server was designed as a "real" SMTP server that delivers
to many destinations. In such a context, authentication is meaningless.
But in a context where you route all mail to a gateway server (such as
your ISPs), then authentication can become realistic (a single
user/password needed to send all mail via such server). But the TCPIP
Services server is not setup to handle this.
And usually, an ISP would allow computers using its own IP blocks to
access its SMTP server without restrictions.
The question of authentication has been asked a number of times here.
And assuming there are people left at TCPIP Services engineering, it is
doubtful they would be given priority on this feature since paying
customers don't request it.
Your best bet is to find an ISP that doesn't require authentication
and/or block port 25 so your own SMTP server can do its job.
David J. Dachtera
My take on his question was similar to my own quandry:
From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
using my ISP's SMTP agent as the up-line forwarder when SMTP
authentication is being enforced?
I haven't yet found a way to do this.
A mechanism similar to this would be helpful, if it existed:
$ DEFINE/SYSTEM/EXEC SMTP$SEND_AUTH "djesys:mypassword"
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Spud Demon
>My take on his question was similar to my own quandry:
>
>From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
>using my ISP's SMTP agent as the up-line forwarder when SMTP
>authentication is being enforced?
Why tie yourself to your ISP's mail server? OpenVMS has one, and it's
fully capable of routing your messages to the right MX domains.
Keeping messages on your own system has the advantage that you can watch the
queue and know if your buddy's server is not responding.
>A mechanism similar to this would be helpful, if it existed:
>
>$ DEFINE/SYSTEM/EXEC SMTP$SEND_AUTH "djesys:mypassword"
Somebody would leave an open relay, get their account revoked, and blame HP.
--Spud Demon spud_demon -at- thundermaker.net
dav...@alpha2.mdx.ac.uk
>"David J. Dachtera" <djes...@spam.comcast.net> writes in article <44D645C4...@spam.comcast.net> dated Sun, 06 Aug 2006 14:40:52 -0500:
>>My take on his question was similar to my own quandry:
>>
>>From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
>>using my ISP's SMTP agent as the up-line forwarder when SMTP
>>authentication is being enforced?
>
>Why tie yourself to your ISP's mail server? OpenVMS has one, and it's
>fully capable of routing your messages to the right MX domains.
>
>Keeping messages on your own system has the advantage that you can watch the
>queue and know if your buddy's server is not responding.
>
Too many mail servers use blacklists such as MAPS DUL or SORBS DUHL to block
mail from such addresses. Hence it is better to send mail out through your
ISP's central mailhubs which shouldn't be blocked.
This can usually be accomplished by either configuring your client to send out
directly through your ISP's mailhub or by configuring your mail server to
forward all of it's mail out through the ISP's mailhub as a smarthost.
However if your ISP's mailhub forces authentication then the latter becomes
impossible unless your mailserver software has some means of providing the
authentication when challenged.
The only solutions in that case are to
1) Get such functionality added to the mailserver software which is what
David wants
or
2) Use a different system as a smarthost which doesn't require such
authentication. A number of providers such as dyndns provide such a service
at a price.
>>A mechanism similar to this would be helpful, if it existed:
>>
>>$ DEFINE/SYSTEM/EXEC SMTP$SEND_AUTH "djesys:mypassword"
>
>Somebody would leave an open relay, get their account revoked, and blame HP.
>
If you are running your own mailserver then you are responsible for making sure
it isn't an open-relay. If you are running an open-relay and your ISP suspends
or closes your account then that is your fault not HPs.
David Webb
Security team leader
CCSS
Middlesex University
Paul Sture
> In article <44d7182d$0$42180$815e...@news.qwest.net>, spud_...@e.THUNDERMAKER.NET (Spud Demon) writes:
>> "David J. Dachtera" <djes...@spam.comcast.net> writes in article <44D645C4...@spam.comcast.net> dated Sun, 06 Aug 2006 14:40:52 -0500:
>>> My take on his question was similar to my own quandry:
>>>
Correct David.
>> >From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
>>> using my ISP's SMTP agent as the up-line forwarder when SMTP
>>> authentication is being enforced?
>> Why tie yourself to your ISP's mail server? OpenVMS has one, and it's
>> fully capable of routing your messages to the right MX domains.
>>
>> Keeping messages on your own system has the advantage that you can watch the
>> queue and know if your buddy's server is not responding.
>>
> Sending mail directly when you have a dynamic address is not a good idea.
> Too many mail servers use blacklists such as MAPS DUL or SORBS DUHL to block
> mail from such addresses. Hence it is better to send mail out through your
> ISP's central mailhubs which shouldn't be blocked.
I have reason to believe that my ISP has in the past suffered from spam
zombies unwittingly run by their customers, so IMHO they did the right
thing by enforcing authentication.
In any case I have found at least one place where dynamic addresses in
my range are, or have been, blacklisted.
Since I am now using cable, and don't need a telco line any more, JF's
suggestion of getting a different ISP would automatically double my
monthly charges for little gain (and at that cost, I'd still have a
dynamic address, and could run into exactly the same problem).
For me, it's just a "would be nice to have" feature.
One alternative I can think of is to use my OS X system to act as a mail
server which can forward from my VMS system using the appropriate
authentication, but I've done zero research on that.
--
Paul Sture
Hoff Hoffman
> For me, it's just a "would be nice to have" feature.
I've passed along a question on this (basically ESMTP SMTP-MTA port
587 submission via the SMTP transport image), and a pointer to this thread.
SMTP servers (MTAs; which is what TCP/IP Services provides) don't
send their submissions traffic to port 587.
The other approaches are to seek and acquire ISP authorization for
your SMTP mail server, or to use an alternate mail client (MSA) to
submit your email.
dav...@alpha2.mdx.ac.uk
I'd raised this issue on the vmsnet.mail.pmdf newsgroup when PMDF became
available to hobbyists and have now formally raised it with Process
(through our local reseller - Essential).
Bob Koehler
> Some time ago, my ISP changed their mail system so that I need to supply
> authentication for outgoing mail (Good Move against spamming zombies).
>
> In Mac Mail, Thunderbird etc, there are settings for supplying
> authentication for outgoing mail.
>
> Does similar exist in TCP/IP Services for VMS?
>
That kind of thing can be fonud in most browsers. Try reading your
email via Mozilla, works for me.
dav...@alpha2.mdx.ac.uk
True enough but doesn't help if you want to run your own mail server.
David Webb
security team leader
CCSS
Middlesex University
Hoff Hoffman
> True enough but doesn't help if you want to run your own mail server.
SMTP mail servers (MTAs) use port 25.
SMTP mail clients (MUAs) use port 25 or (with SMTP-MTA ESMTP RFC2476
support) to the MSA listening on port 587.
I've suggested a modification to the SMTP transport to allow it to
connect into port 587, as the SMTP transport image for the OpenVMS MAIL
utility (SMTP%) is the MUA here.
Basically either the SMTP transport client has to be modified to use
port 587, or there needs to be some sort of a translating gateway here
that accepts connections on 25 and passes them along on 587. Or some
other MAIL client need be used, or a custom SMTP MAIL transport image
need be created, or the ISP needs to designate this OpenVMS system as an
MTA. (Which it is.)
JF Mezei
> The other approaches are to seek and acquire ISP authorization for
> your SMTP mail server, or to use an alternate mail client (MSA) to
> submit your email.
You do realise that you are effgectively suggesting one move off VMS ?
("use an alternate mail client").
The point is that we want VMS to be modern and usable in the current
environment. SMTP is being tightened up in many ways to prevent spam. So
either HP re-hires engineers to do work on the TCPIP Services product,
or you open-source it NOW so that we (the users) can gradually add the
missing features.
JF Mezei
> That kind of thing can be fonud in most browsers. Try reading your
> email via Mozilla, works for me.
You're missing the point. If you want your VMS host to be sending emails
(either via DCL procedures or WEB scripts or interactively), then you
need that authentication capability built into the VMS mail system.
Tom Linden
<jfmezei...@teksavvy.com> wrote:
> Hoff Hoffman wrote:
>> The other approaches are to seek and acquire ISP authorization for
>> your SMTP mail server, or to use an alternate mail client (MSA) to
>> submit your email.
>
> You do realise that you are effgectively suggesting one move off VMS ?
> ("use an alternate mail client").
Nothing wrong with that, and it is a better solution, but then you could
use
soyMail too, which is quite good.
>
> The point is that we want VMS to be modern and usable in the current
> environment. SMTP is being tightened up in many ways to prevent spam. So
> either HP re-hires engineers to do work on the TCPIP Services product,
> or you open-source it NOW so that we (the users) can gradually add the
> missing features.
Or you use a third party product like MX
Hoff Hoffman
> Hoff Hoffman wrote:
>> The other approaches are to seek and acquire ISP authorization for
>> your SMTP mail server, or to use an alternate mail client (MSA) to
>> submit your email.
>
> You do realise that you are effgectively suggesting one move off VMS ?
> ("use an alternate mail client").
Eh? There are various supported and freeware MUAs (mail clients)
available for OpenVMS. I certainly usually end up packaging several
MUAs onto each Freeware, and the SWB (Mozilla) client for OpenVMS offers
a MUA.
> The point is that we want VMS to be modern and usable in the current
> environment. SMTP is being tightened up in many ways to prevent spam.
So you're really and seriously asking for us to violate the RFCs?
(That sort of approach would require justification, too.)
I can understand wanting to have this, but MTAs operate on port 25
and not on port 587. MTAs are not supposed to send to port 587. Which
means you either use an MUA and operate as a client as the ISP expects,
or you negotiate with your ISP to provide authorized port 25 access.
(And if it's not obvious, OpenVMS provides an MUA that operates with its
MTA, and expects the MTAs to be connected per established norms.)
I'd certainly not mind seeing an integrated MUA client for OpenVMS
(either via the existing SMTP% transport, or via some replacement
transport), for those that are using OpenVMS as a client behind an ISP
and need to move to port 587 and into an MSA. And it would not surprise
me if there was such a construct around -- I certainly have the shell of
the transport image around, as do others. (But having an MTA connect
into an MSA is a non-starter without a whole lot more supporting
justification.)
David J. Dachtera
>
> "David J. Dachtera" <djes...@spam.comcast.net> writes in article <44D645C4...@spam.comcast.net> dated Sun, 06 Aug 2006 14:40:52 -0500:
> >My take on his question was similar to my own quandry:
> >
> >From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
> >using my ISP's SMTP agent as the up-line forwarder when SMTP
> >authentication is being enforced?
>
> Why tie yourself to your ISP's mail server? OpenVMS has one, and it's
> fully capable of routing your messages to the right MX domains.
If I wanted to be a mail server admin., I'd start up my own ISP.
JF Mezei
> Eh? There are various supported and freeware MUAs (mail clients)
> available for OpenVMS.
The point being that they bypass VMS as a mail infrastructure to connect
to remote non-VMS servers. And it means that the lack of authentication
for the receiver also means that you cannot support remote clients (for
instance, you own employees connecting to your SMTP server while travelling).
> I can understand wanting to have this, but MTAs operate on port 25
> and not on port 587.
Nobody asked for the MTA to connect to port 587. They asked for the MTA
to support authentication to be available when the MTA is used as a
forwarder to a defined gateway MTA.
> or you negotiate with your ISP to provide authorized port 25 access.
Large ISPs do not negotiate with customers. They are large organisation
totally detached from their customers and who see customers as necessary
evil that must be contained as much as possible.
Paul Sture
I'd better say what triggered my question :-)
I am using Graham Burley's FTP_NW.COM utility to fetch the latest ECO
notifications.
See
http://www.encompasserve.org/~burley/
for details.
I just thought it would be nice to be able to send notifications to the
outside world too.
--
Paul Sture
dav...@alpha2.mdx.ac.uk
Hoff,
If the ISP is using separate incoming and outgoing mail servers they can
set things up to require authentication (using SASL and SMTP AUTH) on the
standard smtp port.
If the ISP is using the same mailhub for both incoming and outgoing mail then
they can set it up to accept authentication using SASL and SMTP AUTH on port 25
but cannot obviously require it without compromising their ability to receive
mail from other organisations. In that case they would have to use the
submission port 587 for this purpose.
I have asked PMDF to add an option into their product to support this type of
authentication (PMDF already supports SASL and SMTP AUTH and the submission
port for connections to it as a server but doesn't currently support
authentication when passing mail out to a ISP smarthost).
Note other MTAs already provide this functionality
see for instance
http://www.sendmail.org/~ca/email/auth.html#smtpclient
Using sendmail as a client with AUTH
http://postfix.state-of-mind.de/patrick.koetter/smtpauth/smtp_auth_mailservers.html
16. SMTP Authentication for Mail servers
and
http://www.hserus.net/wiki/index.php/Exim
David Webb
Security team leader
CCSS
Middlesex University
dav...@alpha2.mdx.ac.uk
>On Mon, 07 Aug 2006 10:32:21 -0700, JF Mezei =>>> The other approaches are to seek and acquire ISP authorization for=
>
>>> your SMTP mail server, or to use an alternate mail client (MSA) to
>>> submit your email.
>>
>
>> ("use an alternate mail client").
>
> =
>
>use
>soyMail too, which is quite good.
>>
I'm not aware of any ISP SMTP authentication methods in SoyMail to send out
mail - you could set smtp-default-host to your ISPs mailhub but as far as I am
aware SoyMail can't be configured to respond to the authentication challenge.
As I recall the previous version Yahmail just sent mail out through the mail
server running on the VMS system.
>> The point is that we want VMS to be modern and usable in the current
>> environment. SMTP is being tightened up in many ways to prevent spam. =
>So
>> either HP re-hires engineers to do work on the TCPIP Services product,=
>
>> or you open-source it NOW so that we (the users) can gradually add the=
>
>> missing features.
>
>Or you use a third party product like MX
PMDF doesn't currently support this option so I'd be surprised if MX does.
dav...@alpha2.mdx.ac.uk
>JF Mezei wrote:
>> Hoff Hoffman wrote:
>>> The other approaches are to seek and acquire ISP authorization for
>>> your SMTP mail server, or to use an alternate mail client (MSA) to
>>> submit your email.
>>
>> You do realise that you are effgectively suggesting one move off VMS ?
>> ("use an alternate mail client").
>
>MUAs onto each Freeware, and the SWB (Mozilla) client for OpenVMS offers
>a MUA.
>
>> environment. SMTP is being tightened up in many ways to prevent spam.
>
>(That sort of approach would require justification, too.)
>
Modern mail servers can accept mail on both the standard smtp port and on
the submission port. However they can also be run on non-standard ports for
both sending and receiving mail. In this instance all outgoing mail will be
sent via the ISP's mailhub hence if the ISP requires use of the submission
port that should not be a problem it is just sending on a non-standard port -
port 587 rather than port 25. The problem is the authentication challenge.
The writers of PMDF (who have authored a number of the RFCs) have supported
use of non-standard ports pretty much forever.
> I can understand wanting to have this, but MTAs operate on port 25
>and not on port 587.
Ports 25 and 587 are the standard default ports. Use of non-standard ports is
not banned by the RFCs.
>MTAs are not supposed to send to port 587. Which
>means you either use an MUA and operate as a client as the ISP expects,
>or you negotiate with your ISP to provide authorized port 25 access.
>(And if it's not obvious, OpenVMS provides an MUA that operates with its
>MTA, and expects the MTAs to be connected per established norms.)
>
You are misinterpretting the established norms since sending to non-standard
ports and SMTP auth for connection to another mailserver is supported by
numerous MTAs including Sendmail, Postfix and Exim
David Webb
Security team leader
CCSS
Middlesex University
> I'd certainly not mind seeing an integrated MUA client for OpenVMS
Martin Vorlaender
> I am using Graham Burley's FTP_NW.COM utility to fetch the latest ECO
> notifications.
>
> See
>
> http://www.encompasserve.org/~burley/
>
> for details.
>
> I just thought it would be nice to be able to send notifications to the
> outside world too.
You do know Ken Farmer's OpenVMS Alert mailing list?
http://www.openvms.org/pages.php?page=Alerts
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: m...@pdv-systeme.de
One OS to bring them all | http://www.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: mar...@radiogaga.harz.de
Hoff Hoffman
> are misinterpretting the established norms since sending to non-standard
> ports and SMTP auth for connection to another mailserver is supported by
> numerous MTAs including Sendmail, Postfix and Exim
In this case, MUAs send to 25 or 587, while MTAs send to 25.
What other protocols and ports might be used here (and I've seen all
manner of non-default and non-standard ports used, and non-default port
schemes including doorbell schemes that unmask other ports) doesn't
really matter here, because the ISP is using 25 for its own transport,
and requesting 587 (the MSA port) for its clients; for the MUAs.
The RFCs are rather clear about not having MTAs connected to MSAs
(for all that the RFCs can actually mean in reality -- more than a few
RFCs around have ambiguitities or run contrary to accepted
implementations), but (as I recall) I did also mention the possibility
of a gateway between 25 and 587.
The intended configuration (from the perspective of the ISP) is a
MUA, meaning you need to use a client package -- and these are available
for OpenVMS, including the mail client inside the Mozilla suite. (Now
as for a MUA transport image, as I mentioned, that would be useful here,
too. Combine it with a POP or IMAP server daemon, and you'd have a full
client-mail configuration -- rather than the existing SMTP server. But
OpenVMS has neither of these pieces.)
Which means you are left to use an MUA on OpenVMS, or negotiate with
the ISP to open 25. (Or to find a gateway to feed between the ISP
environment and the server environment -- POP/IMAP into SMTP, and SMTP
MTA into the MSA -- OpenVMS doesn't have SMTP AUTH on port 25, nor AFAIK
an MSA on 587.)
Now as for adding SMTP AUTH (and likely also MSA support), that's
certainly an entirely reasonable request -- but like the discussions of
the ports this particular ISP is using -- it's not immediately relevant.
If/when the SMTP AUTH TCP/IP Services work (or the SMTP client work)
is accepted as an enhancement (and regardless of what pieces might be
involved), the timeframe involved is inevitably past the horizon that
the original poster will be willing to tolerate. Hence the
recommendation for a MUA that has this -- and which also happens to be
the configuration clearly recommended by and expected by the ISP -- or
to get port 25 opened for this server.
As is my norm for these sorts of newsgroup discussions, I'll pass the
enhancement request along to the OpenVMS business manager.
Paul Sture
> Paul Sture wrote:
>> I am using Graham Burley's FTP_NW.COM utility to fetch the latest ECO
>> notifications.
>>
>> See
>>
>> http://www.encompasserve.org/~burley/
>>
>> for details.
>>
>> I just thought it would be nice to be able to send notifications to
>> the outside world too.
>
> You do know Ken Farmer's OpenVMS Alert mailing list?
>
> http://www.openvms.org/pages.php?page=Alerts
>
I'd forgotten about that. Thanks.
I must admit that I didn't expect my query to generate so many responses :-)
--
Paul Sture
dav...@alpha2.mdx.ac.uk
>dav...@alpha2.mdx.ac.uk wrote:
>> are misinterpretting the established norms since sending to non-standard
>> ports and SMTP auth for connection to another mailserver is supported by
>> numerous MTAs including Sendmail, Postfix and Exim
>
>
with. The default standard port for smtp mail transmission whether from a MUA
or MTA is port 25. The default standard port for message submission from an MSA
is port 587. But those are just defaults. Any particular group of servers and
clients can privately agree to use other non-standard ports.
> What other protocols and ports might be used here (and I've seen all
>manner of non-default and non-standard ports used, and non-default port
>schemes including doorbell schemes that unmask other ports) doesn't
>really matter here, because the ISP is using 25 for its own transport,
>and requesting 587 (the MSA port) for its clients; for the MUAs.
>
Please refer to the links I provided for Sendmail, Postfix and Exim.
All these MTAs support the server providing a username and password when
sending to mail servers which require SMTP AUTH from connecting systems.
(The ISP's mail server has no way of determining whether an incoming connection
is from an MUA or an MTA. The SMTP protocol provides no way for it to make that
distinction. What it can determine is whether the mail is from a user who it
knows by requiring authentication using SMTP AUTH (According to how the
ISP's mail server is setup this may be on the standard SMTP port, The
submission port or some other non-standard port specified by the ISP).
> The RFCs are rather clear about not having MTAs connected to MSAs
>(for all that the RFCs can actually mean in reality -- more than a few
>RFCs around have ambiguitities or run contrary to accepted
>implementations), but (as I recall) I did also mention the possibility
>of a gateway between 25 and 587.
>
Please point to a reference to something in the RFCs which states that
a system performing the functions of an MTA cannot also perform a message
submission. I am unaware of any such proscription.
Indeed rfc2821 section 2.3.3 talking about MUAs and MTAs
specifically warns
"
However, while these terms are used with at least the appearance of great
precision in other environments, the implied boundaries between MUAs
and MTAs often do not match common, and conforming, practises with internet
mail. Hence, the reader should be cautious about inferring the strong
relationships and responsibilities that might be implied if these terms were
used elsewhere.
"
And as I have pointed out many mail servers can perform this function.
David Webb
Security team leader
CCSS
Middlesex University
Hoff Hoffman
> And as I have pointed out many mail servers can perform this function.
Then it would be reasonable to load and run one, if this is required.
Or to use a variant MUA, and particularly one that does support port
587 and SMTP-MTA SMTP AUTH submissions.
Or to clear the port 25 access with the ISP.
Or to use a different platform.
If a particular MTA switches and gateways something (and modifies the
SMTP headers, as is contraindicated in my reading of the RFCs) and
connects into an MSA somewhere as part of passing along the message,
well, bully for it. The TCP/IP Services MTA does not presently offer
this capability, and the present OpenVMS MUA SMTP MAIL transport image
assumes and performs non-AUTH port 25 operations, and (assuming the
enhancement request(s) that could/would/will arise here are accepted and
engineered and released) the timeframe involved is likely well beyond
that of the requirements of the initiator of this sequence.
There are options here. Port 587 submissions via TCP/IP Services MTA
and MUA components are not among these, however.
JF Mezei
> The RFCs are rather clear about not having MTAs connected to MSAs
> (for all that the RFCs can actually mean in reality --
Sorry, but SMTP is meant to be a peer to peer protocol. What it means
is that some clients use additional features of a server which other
clients don't use them.
In the case of an ISP, they want all clients to use autnentication
features. So an SMTP agent that does not support authentication cannot
effectively connect to that ISP's SMTP server.
Like it is not, this is the case. At this point in time, VMS's SMTP
software does not participate properly in today,s SMTP world. It doesn't
even handle greylisting (first attempt results in a non-fatal "try again
later" message, but VMS sees it as a fatal error and never delivers the
message again).
RFCs evolve and new ones get tagged on to expand a protocol. VMS needs
to follow suit.
> The intended configuration (from the perspective of the ISP) is a
> MUA, meaning you need to use a client package -- and these are available
> for OpenVMS, including the mail client inside the Mozilla suite.
Mozilla does not run on all VMS instances, notably not on VAX.
bri...@encompasserve.org
> Hoff Hoffman wrote:
>> The RFCs are rather clear about not having MTAs connected to MSAs
>> (for all that the RFCs can actually mean in reality --
>
>
> Sorry, but SMTP is meant to be a peer to peer protocol. What it means
> is that some clients use additional features of a server which other
> clients don't use them.
Sorry, but it grates on me to hear someone use the terms "client"
and "server" and "peer to peer" in the same sentence as if they
were the same thing.
SMTP is a client server protocol. The roles are clearly delineated
and are not at all symmetric. It is not "peer to peer". And the
ability to use optional extensions to a protocol hardly makes that
protocol "peer to peer".
Certainly, RFC 821 contemplates a store and forward messaging network
of cooperating peers.
However, what RFC 821 describes is a client/server protocol.
(ETRN notwithstanding). SMTP is not the whole banana. It is
just a transport protocol. You could swap out the transport
protocol and still have a functionally identical messaging
network.
JF Mezei
> Sorry, but it grates on me to hear someone use the terms "client"
> and "server" and "peer to peer" in the same sentence as if they
> were the same thing.
>
> SMTP is a client server protocol.
Technically you are right. But a SMTP server can become an SMTP client.
I.E it acts as a server when receiving a message and acts as a client
when sending/forwarding a message.
And in that context, whether a SMTP "engine" receives a call from a MUA
or other SMTP "engine" doesn't make a difference.
The SMTP engine will make spam/relaying differences based on the origin
of an incoming call, not whether the call comes from an MUA or MTA.
To this end, one need not differentiate between an MUA and MTA in the
SMTP context. The "MUA" is generally a scalled down SMTP server that can
only send messages to one SMTP server (gateway) and won't generally
automatically retry sending messages.
And to this end, the SMTP server on VMS looks and acts like an MUA when
it tries to deliver messages to a gateway SMTP server, and as such,
there is nothing wrong in giving it attributes such as authentication.
dav...@alpha2.mdx.ac.uk
>In article <44D8E583...@teksavvy.com>, JF Mezei <jfmezei...@teksavvy.com> writes:
>>> The RFCs are rather clear about not having MTAs connected to MSAs
>>> (for all that the RFCs can actually mean in reality --
>>
>>
>> Sorry, but SMTP is meant to be a peer to peer protocol. What it means
>> is that some clients use additional features of a server which other
>> clients don't use them.
>
>and "server" and "peer to peer" in the same sentence as if they
>were the same thing.
>
>and are not at all symmetric. It is not "peer to peer". And the
>ability to use optional extensions to a protocol hardly makes that
>protocol "peer to peer".
>
>Certainly, RFC 821 contemplates a store and forward messaging network
>of cooperating peers.
>
>However, what RFC 821 describes is a client/server protocol.
>(ETRN notwithstanding). SMTP is not the whole banana. It is
>just a transport protocol. You could swap out the transport
>protocol and still have a functionally identical messaging
>network.
The SMTP protocol is a client/server protocol however some of the systems which
support that protocol can take on both roles.
eg An MTA will be the server when receiving Mail but a client when sending
Mail.
MTA systems communicating can be considered to be peers even though the
protocol itself is a client/server protocol.
Also an MTA receiving mail has no way of knowing from the protocol interaction
whether the system connecting to it is another MTA or an MUA (or for that
matter someone telnetting into the smtp port and typing in the protocol
commands).
Phillip Helbig---remove CLOTHES to reply
<paul.stu...@hispeed.ch> writes:
> Some time ago, my ISP changed their mail system so that I need to supply
> authentication for outgoing mail (Good Move against spamming zombies).
>
> In Mac Mail, Thunderbird etc, there are settings for supplying
> authentication for outgoing mail.
>
> Does similar exist in TCP/IP Services for VMS?
Another option is to switch to an ISP which uses another scheme. As a
satisfied customer, I recommend http://www.dynaccess.de/ . (Note for
non-German-speakers: pages now exist in English as well.) The scheme
there is terribly simple: since DynAccess knows your current IP address
anyway, email from that IP address will be routed through their SMTP
relay server. This is available for the accounts with fees of EUR 85
per year or more. Note also that there are many other features
available, many of which AFAIK aren't offered by other services. In
particular, the option to update much more often (down to every few
seconds) and not just when the IP address changes. (The idea is that if
expected updates are absent, the account can be switched offline so that
e.g. HTTP requests get redirected to a "site is currently down" page, a
backup MX-server for email kicks in, you can be informed of the problem
via email and/or SMS etc.)
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@teksavvy.com> writes:
> The VMS SMTP server was designed as a "real" SMTP server that delivers
> to many destinations. In such a context, authentication is meaningless.
> But in a context where you route all mail to a gateway server (such as
> your ISPs), then authentication can become realistic (a single
> user/password needed to send all mail via such server). But the TCPIP
> Services server is not setup to handle this.
>
> And usually, an ISP would allow computers using its own IP blocks to
> access its SMTP server without restrictions.
>
> The question of authentication has been asked a number of times here.
> And assuming there are people left at TCPIP Services engineering, it is
> doubtful they would be given priority on this feature since paying
> customers don't request it.
>
> Your best bet is to find an ISP that doesn't require authentication
> and/or block port 25 so your own SMTP server can do its job.
For folks with a dynamic IP address, the situation is a bit different.
First, the service doing the dynamic-DNS update might be independent of
the ISP assigning the IP address. Yes, at least one dynamic-DNS
provider, http://www.dynaccess.com/, knows your current IP and will
allow mail through their SMTP relay server based on that IP (and of
course take appropriate steps if you send spam). Also, even if port 25
is not blocked, this might not be much use, since in the fight against
spam many email servers don't accept email from dynamic IP addresses.
Yes, it is a coarse filter, but is sometimes necessary.
Personally, after I moved from fixed IP addresses with ISDN to a dynamic
IP address with DSL, I could TECHNICALLY do everything myself, but ran
into the "we don't accept email from dynamic IP addresses" problem. I
then found http://www.dynaccess.com/ and that solved my problem. In
fact, it's even better than doing everything myself, since if due to
some technical problem my cluster is offline with respect to the world,
a backup MX server will kick in, HTTP requests will get redirected, I'll
get informed by email (obviously, also to an address not on my cluster)
and/or SMS etc. And the prices are quite reasonable. Highly
recommended. (Note: I don't receive any commission for recommending
them; I'm just a satisfied customer and, since they offer many services
"similar" dynamic-DNS providers don't, I think many folks here with a
VMS machine at home might be interested. Additional note: one can run
their Perl script for dynamic-DNS updates (regular updates, not just
when the IP address changes), but I wrote my own update client using DCL
and LYNX in batch mode.)
Phillip Helbig---remove CLOTHES to reply
spud_...@e.THUNDERMAKER.NET (Spud Demon) writes:
> "David J. Dachtera" <djes...@spam.comcast.net> writes in article <44D645C4...@spam.comcast.net> dated Sun, 06 Aug 2006 14:40:52 -0500:
> >My take on his question was similar to my own quandry:
> >
> >From my hobbyist Alpha, how to I MAIL something to an SMTP recipient
> >using my ISP's SMTP agent as the up-line forwarder when SMTP
> >authentication is being enforced?
>
> Why tie yourself to your ISP's mail server? OpenVMS has one, and it's
> fully capable of routing your messages to the right MX domains.
Technically, yes. Practically, many folks don't accept email from
dynamic IP addresses.