[RBL] Current status?

In article <g9pl82$lh7$4@online.de>,
[email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=blue]
> In article <t_Wvk.2076$U5.1028@newsb.telia.net>,
> =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com>
> writes:
>[color=green][color=darkred]
>> >> Log watchers, webcam watchers,
>> >> etc, anything which sends notification by email when something
>> >> "interesting" happens, using its own built-in mail server;[/color]
>>
>> *Server* ?? I set up my cheap Zyxel DSL modem/router to send
>> notifications to me, but it not a *server*. It uses whatever mail
>> server it get's after doing a DSN-MX lookup on the receiver
>> address, and that should be the official SMTP server of my
>> ISP, as far as I understand.
>>
>> Why whould anything just needing to *send* a mail have a
>> smtp *server* implementation ?[/color]
>
> You use "server" to mean "receiving end". A more general use, intended
> here, is "handles traffic". Thus, incoming server and outgoing server.
> You are sending your email TO the proper receiving server (via MX), but
> it is still coming from your machine, not an "official email server".
> Technically, there is no problem with your scheme, but in practice, such
> machines on dial-up, volatile IP addresses are the main source of spam,
> and are thus blocked by more and more people.
>
> Many STMP servers are neither senders nor receivers, but relays.[/color]

Actually, the correct terminology is MUA and MTA.
MUA = Mail User Agent.
MUA's originate and terminate email.

MTA = Mail Transport Agent
MTA'a exchange email across the INTERNET.

Nothing but MTA's should talk between email domains. No MUA shoud be
allowed to acess anything but the local MTA. Thus the reason for blocking
port 25 at your firewall for all internal hosts other than your designated
MTA(s). User machines should never be considered MTA's. MTA's are the
machines with the MX record in tghe DNS system. Violating this simple
network engineering principle is why we have the SPAM probledm that we have.
As for relaying, some MTA's relay. One should be very careful about who
one relays for. You shold relay for your internal machines (all the MUA's)
as that is the purpose of an MTA. You should not relay for external
machines and if you do, that is a real quick way to find yourself on
a blacklist.

Email is really not that hard to manage.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
[email]billg999@cs.scranton.edu[/email] | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

In article <AkZvk.2077$U5.1295@newsb.telia.net>,
Jan-Erik Söderholm <jan-erik.soderholm@telia.com> writes:[color=blue]
> Phillip Helbig---remove CLOTHES to reply wrote:
>[color=green]
>> such
>> machines on dial-up, volatile IP addresses are the main source of spam,[/color]
>
> I do have a hard time thinking that *dial up* has
> that much to do with modern spam, has it ?[/color]

The term "dial-up" today pretty much refers to any host that get's
its address dynamically. No machine that gets it's address dynamically
should be trying to send email to anyone other than its own internal
MTA. Most legitimate email MTA's will refuse a connection from a
machine from outside their domain that can be determined to be using
a dynamically assigned ip address.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
[email]billg999@cs.scranton.edu[/email] | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

In article <g9pl0j$lh7$2@online.de>,
[email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=blue]
> In article
> <8c328cb8-33b0-42e2-b590-5aab5a7b2670@w1g2000prk.googlegroups.com>,
> [email]johnwallace4@yahoo.co.uk[/email] writes:
>[color=green]
>> Enforcing "email from recognised SMTP servers only" would indeed get
>> rid of much spam instantly, and is a tactic already used by some folks
>> to reject *incoming* mail, but it would also break hundreds of little
>> convenience Windows apps that have their own mailsenders built in, and
>> inconvenience millions of their users. Log watchers, webcam watchers,
>> etc, anything which sends notification by email when something
>> "interesting" happens, using its own built-in mail server; they would
>> all need their user/installer to actually know their ISP's SMTP server
>> address so they could do the setup properly. How many PC users
>> actually know or care much about that kind of thing?[/color]
>
> Perhaps true. On the other hand, such machines are the source of most
> SPAM today, taken over by viruses etc sending spam without the owner
> knowing, and without sending too many from one machine within a given
> time (a characteristic some folks used to use to identify possible
> sources of spam). I[/color]

Which is why something as simple as the ISP blocking outgoing traffic
to any addrfess wirth port 25 for all internal machines other than thier
MTA is a good idea and would eliminate the largest source of SPAM.
[color=blue]
> think it would be a good idea that if such little
> convenience apps were to be used, the user would have to enter the name
> of a mailserver.[/color]

It should not even be thier choice. Either send tot he local MTA or
have the connection blocked. It's really that simple!!

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
[email]billg999@cs.scranton.edu[/email] | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

Jan-Erik Söderholm wrote:[color=blue][color=green][color=darkred]
>>> Log watchers, webcam watchers,
>>> etc, anything which sends notification by email when something
>>> "interesting" happens, using its own built-in mail server;[/color][/color]
>
>
> *Server* ?? I set up my cheap Zyxel DSL modem/router to send
> notifications to me, but it not a *server*. It uses whatever mail
> server it get's after doing a DSN-MX lookup on the receiver
> address, and that should be the official SMTP server of my
> ISP, as far as I understand.[/color]

The DNS lookup will tell it the SMTP server of the *destination*
ISP, not the originating ISP. It needs to do the MX lookup
on the sender address, but even that is often not correct, since
many ISPs and other businesses use a different server for outbound
mail than for inbound mail.

MX records exist so that external mail servers can find the
domain's inbound servers, not so that internal mail clients
can find the domain's outbound servers.

AKAIK, there is no standard, reliable way for a client to
identify its own SMTP server for sending messages. The
person setting up the client generally needs to be *told*
this by the networking powers that be, and then set up the
client appropriately. I think some random windows programs
peek into the Outlook configuration to try to determine the
SMTP server, but if you are using some other mail client on
the PC, that probably won't work or may provide a bogus or
obsolete answer.

The SMTP server should be happy to relay mail on behave of
any client within the originating domain, but many have
additional sanity checks to try to limit SPAM, such as
making sure the various "sender" names are valid etc.
Right now, I'm fighting with configuring a system at a
customer site that wants to send problem notification emails
to various people at the customer, and also to our support
department and (possibly) to our support department's home
email addresses and to our pager service. (We want to get
notified even if our mail server is down.) The customer's
outbound SMTP server will relay mail from "username@host.domain.com",
but not from "username@domain.com" unless "username" is a valid mail
recipient at domain.com. However, many external SMTP servers
won't take mail from "@host.domain.com" since the customer's
internal DNS isn't visible to the outside world. (The
address and ptr records for the SMTP servers are externally
visible, but thousands of internal servers, workstations, PCs,
routers, etc. are not.) So the bottom line is I can send
mail from "username@host.domain.com" to one support person's
home email which is @gmail.com, but not to my home email
which is @verizon.net. (I've white-listed "*.domain.com"
on our external email service, so the client system can
send to "username@egh.com") On the other hand, I can send
mail from "known.user@domain.com" to anyone in the world (that I've
tried so far), but "known.user" has to be a known email user at
domain.com, or the customer's SMTP server won't forward it.
(I can't send directly to the destination SMTP server because
the customer's firewall blocks outbound SMTP except from their
outbound servers.)

This leads to 2 problems. 1) I've figured out how to
coerce UCX (really HP TCP/IP Services for OpenVMS, but that
is too damn long to type) into using "domain.com" instead
of "host.domain.com", but I haven't figured out how to make
it send from "known.user" instead of "username". 2) I don't
want to use an existing customer employee's email username
(such as the sytem administrator's username) because I don't
want them getting annoyed with bounces, etc., especially
while testing it. Also, if the employee gets reassigned,
the mail would no longer be relevent to them, and if they
leave the company, the email address will most likely no
longer be valid. (It's pretty much a turnkey system, which
means the customer handles day-to-day operations, but we
deal with anything exceptional, such as crashes and hardware
or software failures.) So I need to get the customer's
network/mail people to supply us with a fake email address
and to forward bounces, undeliverable mail, etc. somewhere
useful (like back to us) so we know when somethings gone
wrong.

Actually, 3 problems, since right now no one can respond
to mail from "user@host.domain.com" (though I think we can
jam a "reply-to:" header into the mail to fix this.)

Actually 4 problems, since the VMS V8.3 version of MIME
seems to be broken; one of the things we want to automail
is reports in the form of comma-separated lists that
can be imported into a spread-sheet by the recipient,
but MIME is messing them up somehow. (The MIME V1.8 in Alpha
V7.3-2 seems to work okay, both with UCX and TCPware,
but I think the current MIME V1.93 on both Itanium and
Alpha is sticking a blank line in the headers somewhere...)

[color=blue]
>
> Why whould anything just needing to *send* a mail have a
> smtp *server* implementation ?[/color]

Because relaying mail is the principle function of an SMTP
server?
[color=blue]
>
> Jan-Erik.[/color]


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

Bill Gunshannon wrote:[color=blue]
> In article <g9pl82$lh7$4@online.de>,
> [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:
>[color=green]
>>In article <t_Wvk.2076$U5.1028@newsb.telia.net>,
>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com>
>>writes:
>>
>>[color=darkred]
>>>>>Log watchers, webcam watchers,
>>>>>etc, anything which sends notification by email when something
>>>>>"interesting" happens, using its own built-in mail server;
>>>
>>>*Server* ?? I set up my cheap Zyxel DSL modem/router to send
>>>notifications to me, but it not a *server*. It uses whatever mail
>>>server it get's after doing a DSN-MX lookup on the receiver
>>>address, and that should be the official SMTP server of my
>>>ISP, as far as I understand.
>>>
>>>Why whould anything just needing to *send* a mail have a
>>>smtp *server* implementation ?[/color]
>>
>>You use "server" to mean "receiving end". A more general use, intended
>>here, is "handles traffic". Thus, incoming server and outgoing server.
>>You are sending your email TO the proper receiving server (via MX), but
>>it is still coming from your machine, not an "official email server".
>>Technically, there is no problem with your scheme, but in practice, such
>>machines on dial-up, volatile IP addresses are the main source of spam,
>>and are thus blocked by more and more people.
>>
>>Many STMP servers are neither senders nor receivers, but relays.[/color]
>
>
> Actually, the correct terminology is MUA and MTA.
> MUA = Mail User Agent.
> MUA's originate and terminate email.
>
> MTA = Mail Transport Agent
> MTA'a exchange email across the INTERNET.
>
> Nothing but MTA's should talk between email domains. No MUA shoud be
> allowed to acess anything but the local MTA. Thus the reason for blocking
> port 25 at your firewall for all internal hosts other than your designated
> MTA(s). User machines should never be considered MTA's. MTA's are the
> machines with the MX record in tghe DNS system. Violating this simple
> network engineering principle is why we have the SPAM probledm that we have.
> As for relaying, some MTA's relay. One should be very careful about who
> one relays for. You shold relay for your internal machines (all the MUA's)
> as that is the purpose of an MTA. You should not relay for external
> machines and if you do, that is a real quick way to find yourself on
> a blacklist.
>
> Email is really not that hard to manage.
>
> bill
>[/color]

Yup. I think that many of the problems arise because MUAs use the same
protocol (SMTP) and port (25) to send mail to MTAs as MTAs use to relay
mail to each other. On the other hand MTAs talk to MUAs (when delivering
mail) using either of 2 different protocols (that I know of), POP3 on
port 110 and IMAP on port 143. (I don't think anything does POP2 on
port 109 any more.) I think if the mail origination and mail relay
functions and protocols had been kept distinct from the start, everything
would be much cleaner and under better control. For example, the way
you want to authenticate a mail originator is very different from the
way you want to authenticate a mail transport agent.

In their defense, SMTP is a "push" protocol (both for originating and
relaying mail), but POP3 and IMAP are "pull" protocols, so there's a
lot more commonality between an MUA sending to an MTA, and an MTA
forwarding mail to another MTA, than between them and mail delivery.
Also, these protocols originated before SPAM was an issue.


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

In article <6ib9tbFpklicU1@mid.individual.net>, [email]billg999@cs.uofs.edu[/email] (Bill Gunshannon) writes:[color=blue]
>In article <g9pl82$lh7$4@online.de>,
> [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=green]
>> In article <t_Wvk.2076$U5.1028@newsb.telia.net>,
>> =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com>
>> writes:
>>[color=darkred]
>>> >> Log watchers, webcam watchers,
>>> >> etc, anything which sends notification by email when something
>>> >> "interesting" happens, using its own built-in mail server;
>>>
>>> *Server* ?? I set up my cheap Zyxel DSL modem/router to send
>>> notifications to me, but it not a *server*. It uses whatever mail
>>> server it get's after doing a DSN-MX lookup on the receiver
>>> address, and that should be the official SMTP server of my
>>> ISP, as far as I understand.
>>>
>>> Why whould anything just needing to *send* a mail have a
>>> smtp *server* implementation ?[/color]
>>
>> You use "server" to mean "receiving end". A more general use, intended
>> here, is "handles traffic". Thus, incoming server and outgoing server.
>> You are sending your email TO the proper receiving server (via MX), but
>> it is still coming from your machine, not an "official email server".
>> Technically, there is no problem with your scheme, but in practice, such
>> machines on dial-up, volatile IP addresses are the main source of spam,
>> and are thus blocked by more and more people.
>>
>> Many STMP servers are neither senders nor receivers, but relays.[/color]
>
>Actually, the correct terminology is MUA and MTA.
>MUA = Mail User Agent.
>MUA's originate and terminate email.
>
>MTA = Mail Transport Agent
>MTA'a exchange email across the INTERNET.
>
>Nothing but MTA's should talk between email domains. No MUA shoud be
>allowed to acess anything but the local MTA. Thus the reason for blocking
>port 25 at your firewall for all internal hosts other than your designated
>MTA(s).
>User machines should never be considered MTA's.[/color]

Totally agree.
[color=blue]
>MTA's are the machines with the MX record in tghe DNS system.[/color]

Not necessarily. Many organisations have separate MTAs for incoming and
outgoing mail. Only those which accept incoming mail are listed in the DNS MX
records.

As well as blocking connections to port 25 on external systems from your
internal systems (apart from for your designated MTAs) you should also
block connections from the external world to your internal systems on port 25
(apart again from your designated MTAs). This stops someone setting up an
internal system as an MTA which sends out through your designated MTAs.
Because such systems are often poorly configured and are accessible from the
outside world they maybe open-relays and because they send out through your
designated MTAs they may cause your MTAs to be listed as "secondary"
open-relays on certain blacklists.


David Webb
Security team leader
CCSS
Middlesex University



[color=blue]
> Violating this simple
>network engineering principle is why we have the SPAM probledm that we have.
>As for relaying, some MTA's relay. One should be very careful about who
>one relays for. You shold relay for your internal machines (all the MUA's)
>as that is the purpose of an MTA. You should not relay for external
>machines and if you do, that is a real quick way to find yourself on
>a blacklist.
>
>Email is really not that hard to manage.
>
>bill
>
>--
>Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
>billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
>University of Scranton |
>Scranton, Pennsylvania | #include <std.disclaimer.h>[/color]

In article <AkZvk.2077$U5.1295@newsb.telia.net>,
=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com>
writes:
[color=blue]
> Phillip Helbig---remove CLOTHES to reply wrote:
>[color=green]
> > such
> > machines on dial-up, volatile IP addresses are the main source of spam,[/color]
>
> I do have a hard time thinking that *dial up* has
> that much to do with modern spam, has it ?[/color]

OK, not real dialup with the acoustic modem, but in the sense of "I want
to go online now; my provider should give me an IP address", which
probably takes place via DSL in most cases today.

In article <7h%vk.609$393.335@trnddc05>, John Santos <john@egh.com> writes:[color=blue]
>Bill Gunshannon wrote:[color=green]
>> In article <g9pl82$lh7$4@online.de>,
>> [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:
>>[color=darkred]
>>>In article <t_Wvk.2076$U5.1028@newsb.telia.net>,
>>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com>
>>>writes:
>>>
>>>[/color][/color]
>
>Yup. I think that many of the problems arise because MUAs use the same
>protocol (SMTP) and port (25) to send mail to MTAs as MTAs use to relay
>mail to each other.[/color]

Modern MTAs can be configured to allow mail clients to submit mail to them on
the mail submission port (port 587) rather than port 25. See RFC 2476
[url]http://www.faqs.org/rfcs/rfc2476.html[/url]

[color=blue]
> On the other hand MTAs talk to MUAs (when delivering
>mail) using either of 2 different protocols (that I know of), POP3 on
>port 110 and IMAP on port 143. (I don't think anything does POP2 on
>port 109 any more.)[/color]

Logically there are three parties involved not two.
MTA, MUA and Message store.

The MTA delivers mail to another MTA or to a message store.
The MUA originates mail and sends it to a MTA.
Mail clients generally incorporate the above MUA functionality together with
the ability to display and manipulate mail in the message store.

POP and IMAP are protocols used to access and manipulate the message store.
They are NOT used to deliver mail to the message store.

Note.

The SMTP servers which come with the TCPIP stacks (TCPWARE, MULTINET or TCPIP
SERVICES/UCX) are NOT fully fledged modern MTAs. For that you would need either
PMDF or MX.
(
PMDF is a commercial product but is available free for hobbyist use.
MX is now an open-source free product see
[url]http://www.madgoat.com/[/url]
However I'm not aware of anyone currently continuing development of MX.
)


David Webb
Security team leader
CCSS
Middlesex University

[color=blue]
>I think if the mail origination and mail relay
>functions and protocols had been kept distinct from the start, everything
>would be much cleaner and under better control. For example, the way
>you want to authenticate a mail originator is very different from the
>way you want to authenticate a mail transport agent.
>
>In their defense, SMTP is a "push" protocol (both for originating and
>relaying mail), but POP3 and IMAP are "pull" protocols, so there's a
>lot more commonality between an MUA sending to an MTA, and an MTA
>forwarding mail to another MTA, than between them and mail delivery.
>Also, these protocols originated before SPAM was an issue.
>
>
>--
>John Santos
>Evans Griffiths & Hart, Inc.
>781-861-0670 ext 539[/color]

In article <4w_vk.522$1a2.373@trnddc04>, John Santos <john@egh.com>
writes:
[color=blue]
> AKAIK, there is no standard, reliable way for a client to
> identify its own SMTP server for sending messages. The
> person setting up the client generally needs to be *told*
> this by the networking powers that be, and then set up the
> client appropriately.[/color]

$ TCPIP SET CONF SMTP/GATEWAY=ALTERNATE=<host>

In my case:

Alternate gateway: SMTP-RELAY.DYNACCESS.DE
[color=blue]
> This leads to 2 problems. 1) I've figured out how to
> coerce UCX (really HP TCP/IP Services for OpenVMS, but that
> is too damn long to type) into using "domain.com" instead
> of "host.domain.com",[/color]

Substitute domain?
[color=blue]
> but I haven't figured out how to make
> it send from "known.user" instead of "username".[/color]

DEFINE TCPIP$SMTP_FROM <sender address> ?

In article <g9qu48$f7b$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
writes:
[color=blue]
> As well as blocking connections to port 25 on external systems from your
> internal systems (apart from for your designated MTAs) you should also
> block connections from the external world to your internal systems on port 25
> (apart again from your designated MTAs). This stops someone setting up an
> internal system as an MTA which sends out through your designated MTAs.
> Because such systems are often poorly configured and are accessible from the
> outside world they maybe open-relays and because they send out through your
> designated MTAs they may cause your MTAs to be listed as "secondary"
> open-relays on certain blacklists.[/color]

I receive email locally on my VMS cluster, so the outside world has to
be able to connect. Misusing me as a relay? Not a problem:

SMTP Configuration

Options
Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
Maximum interval: 3 00:00:00.00 HEADERS

I think NORELAY is even the default.

In article <g9r0lf$g15$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
writes:
[color=blue]
> The SMTP servers which come with the TCPIP stacks (TCPWARE, MULTINET or TCPIP
> SERVICES/UCX) are NOT fully fledged modern MTAs. For that you would need either
> PMDF or MX.[/color]

What's missing?

In article <g9r0rh$2qe$3@online.de>, [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=blue]
>In article <g9qu48$f7b$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
>writes:
>[color=green]
>> As well as blocking connections to port 25 on external systems from your
>> internal systems (apart from for your designated MTAs) you should also
>> block connections from the external world to your internal systems on port 25
>> (apart again from your designated MTAs). This stops someone setting up an
>> internal system as an MTA which sends out through your designated MTAs.
>> Because such systems are often poorly configured and are accessible from the
>> outside world they maybe open-relays and because they send out through your
>> designated MTAs they may cause your MTAs to be listed as "secondary"
>> open-relays on certain blacklists.[/color]
>
>I receive email locally on my VMS cluster, so the outside world has to
>be able to connect. Misusing me as a relay? Not a problem:
>
>SMTP Configuration
>
>Options
>Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
>Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
>Maximum interval: 3 00:00:00.00 HEADERS
>
>I think NORELAY is even the default.
>[/color]
In which case your system should either

1) Be one of your designated MTAs
or
2) Send and receive its mail through your organisations designated MTAs

NORELAY may be good enough - I haven't really looked at a UCX SMTP
configuration in almost a decade. But if your mailserver was just one of a large
number in a big domain which I was responsible for I wouldn't want to rely on
you and all those others outside my direct control having set them up correctly
to prevent inappropriate relaying.

At Middlesex University we were getting lots of people (especially in the
computer science department) setting up a Linux or other server and just
installing Sendmail or another mailserver. Before we put in the above block
(a longtime ago now) we were getting such internal mailservers setup without
notice fairly regularly and lots of them were badly configured and open-relays.


David Webb
Security team leader
CCSS
Middlesex University

In article <g9r2je$56r$5@online.de>, [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=blue]
>In article <g9r0lf$g15$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
>writes:
>[color=green]
>> The SMTP servers which come with the TCPIP stacks (TCPWARE, MULTINET or TCPIP
>> SERVICES/UCX) are NOT fully fledged modern MTAs. For that you would need either
>> PMDF or MX.[/color]
>
>What's missing?
>[/color]
A quick list from my knowledge of UCX SMTP compared to PMDF

Generic address rewriting for centralised naming etc
Callouts to antivirus/anti-spam products (content scanning products etc)
SMTP AUTH/SASL both client and server
LDAP lookups
Support for SMTP SUBMISSION
SPF/SRS
SMTP/TLS (though this is an extra cost item for non-hobbyists)
Ability to setup separate channels with different options for sending to
different MTAs
Header trimming
Addition of own headers


(
I can't remember does UCX SMTP server support EHLO responses such as SIZE ?
TCPWARE and MULTINET probably do but I'm not sure about TCPIP Services.
)

That is just a few off the top of my head. The SMTP Servers which come with
the TCPIP stacks are just meant to be very simple systems which receive mail for
local users and send mail from local users. A fully fledged MTA can also act as
a central mailhub which directs mail to multiple internal and external systems
in a controlled manner. They are much larger more flexible systems.


David Webb
Security team leader
CCSS
Middlesex University

[email]david20@alpha2.mdx.ac.uk[/email] wrote:
[color=blue]
> The SMTP Servers which come with
> the TCPIP stacks are just meant to be very simple systems which receive mail for
> local users and send mail from local users.[/color]

OK.
And if *that* is what you need, would you say that the
smtp parts of TCPIP Services are OK as-is ?

In article <6iakmbFpl207U2@mid.individual.net>, [email]billg999@cs.uofs.edu[/email] (Bill Gunshannon) writes:[color=blue]
>
> Not really. Those particular devices should be sending their email to
> the real mailserver which should be the only one communicating with mail
> servers in the the outside world. If network/system managers, in particular
> ISP's, followed this rule 99% of SPAM cold be dealt with in ver short order.[/color]

The problem isn't the path, it's the sending. They want to send via
SMTP, not POP, IMAP, or some other client protocol. As far as the
"security experts" are concerned, only servers send via SMTP.

I can't really fault a COTS vendor for sending email via SMTP.

In article <g9r4i6$h1r$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
writes:
[color=blue][color=green]
> >I receive email locally on my VMS cluster, so the outside world has to
> >be able to connect. Misusing me as a relay? Not a problem:
> >
> >SMTP Configuration
> >
> >Options
> >Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
> >Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
> >Maximum interval: 3 00:00:00.00 HEADERS
> >
> >I think NORELAY is even the default.
> >[/color]
> In which case your system should either
>
> 1) Be one of your designated MTAs
> or
> 2) Send and receive its mail through your organisations designated MTAs[/color]

All mail I send anywhere via TCPIP goes through the host specified as
the alternate gateway. The highest-priority MX record is the WAN
address of my LAN, which gets forwarded to the cluster alias. Anyone
can try send email to this, as far as I'm concerned. (I could have the
highest-priority record point to another MX server---which I use only as
backup servers, which kick in when I am not directly reachable---but
this has the disadvantage that these servers would have to accept mail
to non-existent users on my system which, when delivered to me, would
bounce; most of this would create backscatter spam.) Most connection
attempts to it, however, are dropped because the source is in an RBL.

In article <K0lRKSObFuvg@eisner.encompasserve.org>, [email]koehler@eisner.nospam.encompasserve.org[/email] (Bob Koehler) writes:[color=blue]
>In article <6iakmbFpl207U2@mid.individual.net>, [email]billg999@cs.uofs.edu[/email] (Bill Gunshannon) writes:[color=green]
>>
>> Not really. Those particular devices should be sending their email to
>> the real mailserver which should be the only one communicating with mail
>> servers in the the outside world. If network/system managers, in particular
>> ISP's, followed this rule 99% of SPAM cold be dealt with in ver short order.[/color]
>
> The problem isn't the path, it's the sending. They want to send via
> SMTP, not POP, IMAP, or some other client protocol. As far as the
> "security experts" are concerned, only servers send via SMTP.
>
> I can't really fault a COTS vendor for sending email via SMTP.
>[/color]
Your "security experts" are talking nonsense. SMTP is used to send mail
both MUA to MTA and MTA to MTA.

POP and IMAP cannot be used to send mail since that is NOT their function.
POP and IMAP just connect to a mail store and access or manipulate mail.

The MUA should be configured to send via the organisations local MTA usually
referred to as configuring the mail client to send via a smarthost.

David Webb
Security team leader
CCSS
Middlesex University

In article <g9rs24$svq$1@online.de>, [email]helbig@astro.multiCLOTHESvax.de[/email] (Phillip Helbig---remove CLOTHES to reply) writes:[color=blue]
>In article <g9r4i6$h1r$1@south.jnrs.ja.net>, [email]david20@alpha2.mdx.ac.uk[/email]
>writes:
>[color=green][color=darkred]
>> >I receive email locally on my VMS cluster, so the outside world has to
>> >be able to connect. Misusing me as a relay? Not a problem:
>> >
>> >SMTP Configuration
>> >
>> >Options
>> >Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
>> >Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
>> >Maximum interval: 3 00:00:00.00 HEADERS
>> >
>> >I think NORELAY is even the default.
>> >[/color]
>> In which case your system should either
>>
>> 1) Be one of your designated MTAs
>> or
>> 2) Send and receive its mail through your organisations designated MTAs[/color]
>
>All mail I send anywhere via TCPIP goes through the host specified as
>the alternate gateway. The highest-priority MX record is the WAN
>address of my LAN, which gets forwarded to the cluster alias.[/color]

So your alternate gateway and MX record host are your designated MTAs which
should be allowed to communicate with the outside world over port 25.
Any other systems on your internal network which wish to send mail out should
send out either directly or indirectly through the same alternate gateway.
Any mail for users on any other internal mail system should receive mail by it
first being passed to the MX system which then forwards it onto the internal
system. Hence the other internal systems do not require to open connections
directly to port 25 on arbitrary external systems or to have arbitrary
external systems connecting directly to port 25 on them. Your firewall can
therefore block those other internal systems from attempting such port 25
connections.

(You mention the WAN address of your LAN which suggests that you probably have
an internal network which is using dynamic NAT. Hence NAT is probably taking
care of stopping direct external connections to your other internal systems on
port 25 anyway.)

David Webb
Security team leader
CCSS
Middlesex University

[color=blue]
> Anyone
>can try send email to this, as far as I'm concerned. (I could have the
>highest-priority record point to another MX server---which I use only as
>backup servers, which kick in when I am not directly reachable---but
>this has the disadvantage that these servers would have to accept mail
>to non-existent users on my system which, when delivered to me, would
>bounce; most of this would create backscatter spam.) Most connection
>attempts to it, however, are dropped because the source is in an RBL.
>[/color]

In article <Hy9wk.2079$U5.1312@newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@telia.com> writes:[color=blue]
>david20@alpha2.mdx.ac.uk wrote:
>[color=green]
>> The SMTP Servers which come with
>> the TCPIP stacks are just meant to be very simple systems which receive mail for
>> local users and send mail from local users.[/color]
>
>OK.
>And if *that* is what you need, would you say that the
>smtp parts of TCPIP Services are OK as-is ?[/color]

Strange question. Obviously if a program provides all that you need then
that program is OK for your needs.
For my needs at the University with systems acting as central mailhubs the
functionality of PMDF is much better. For my hobbyist system at home I might be
able to live with the reduced functionality of one of the TCPIP stacks' SMTP
servers but ancillary features of PMDF such as the ability of PMDF MAIL to
send MIME mail without having to mess around with external MIME tools etc tip
the balance firmly in favour of using PMDF.

Or are you asking whether the SMTP server provided by TCPIP services works
properly ? Since I haven't used it in anger for over ten years I can't really
comment upon how well it works.


David Webb
Security team leader
CCSS
Middlesex University

[email]david20@alpha2.mdx.ac.uk[/email] wrote:
[color=blue]
> Or are you asking whether the SMTP server provided by TCPIP services works
> properly ? Since I haven't used it in anger for over ten years I can't really
> comment upon how well it works.[/color]

The SMTP server on VMS has one good thing others may not have: the
ability to trace/log the 821 dialogue between two MTAs. So when one
server refuses your messages, you can trace the dialogue and try to see why.

Unfortunatly, this feature is useful/needed because the TCPIP Services
SMTP server never returns the real error codes issued by the remote
server, it generates its own absolutely useless error codes.

The receiver's SPAM features (IP blocks RBLs and need to have reverse
transaltion is sufficient for me. But lack of authentication capability
on the receiver is a real drawback.

I'd say that the TCPIP Services SMTP server/receiver are far from being
enterprise ready. Postfix, which comes even on Mac desktops is a far
more enterprise ready SMTP server.


And I do not believe HP has any plans to seriously improve the SMTP server.