Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>> MTA's are capable of relaying. But if they are configured correctly
>> they do not, except to intranets. Spammers love those which are
>> configured as open relays. They have lists of them all over the world.
>
> I like the way you wobble back and forth on that.
> It's not a realy - except when it is.
>

Nope, I stand that most public MTA's are not relays.

> And then that slick way you seguay from relays, to open relays - as if
> all relays were open.
>

I never said all relays were open relays. Just that spammers like the
ones out there.

> That last, of course, is why I suggested that the OP use an SSL secured
> mail relay.
>

Which has absolutely no effect on whether the relay is secure or not.
All SSL does is encrypt the data.

>> And POP refers to Post Office Protocol - a protocol for RETRIEVING
>
> Actually, that's just one definition in just one context. In fact, POP
> is an engineering term, not limited to the email, that means
> "Point-of-Presence".
>

When dealing with email POP is not a "Point-of-Presence". Check your
terminology to understand what it means - if you are capable, of course.

> Thus, like I said a Message Transfer Agent that doesn't transfer (relay)
> the messages is just a POP.
>
>

No. Two entirely different things. None of the MTA's are capable of
providing POP services, and none of the POP servers are capable of
handling SMTP traffic.

>
>
>> messages. POP servers by themselves are not capable of receiving
>> email using the SMTP protocol (the one used for sending mail on the
>> internet). You need an MTA to receive the email and deliver it to the
>> POP server.
>
> Hmmm - if only there were an engineering term to describe that "receive
> and deliver" process; a word that engineers have been using since the
> first bucket brigade. Something like "replay" but without the sports
> metaphor?

When an MTA receives a message and places it in a POP (or IMAP) mailbox,
it is called "Delivery", not relay. Relay is used to indicate passing
on to another MTA.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> I like the way you wobble back and forth on that.
>> It's not a realy - except when it is.
>
> Nope, I stand that most public MTA's are not relays.

OK, Jerry - but that requires a very wrong interpretation of the word
"Transfer".

Seriously - on this I consider myself an honest expert. Back in 95, I
built the first Fax-Over-IP protocol, as you've heard me say once or
twice before.

In that effort, I spent a year *constantly* consulting with Marshall
Rose and he gave me an excellent education on this. If you don't know
who he is, check the SMTP specification; his name is on it.

I can't claim his expertise as my own - but when you consider that MTA
stands for Message Transfer Agent, the truth that it is a relay becomes
quite self-evident.


>> That last, of course, is why I suggested that the OP use an SSL
>> secured mail relay.
>
> Which has absolutely no effect on whether the relay is secure or not.
> All SSL does is encrypt the data.

Wow - could you BE more self-contradictory?


> When an MTA receives a message and places it in a POP (or IMAP) mailbox,
> it is called "Delivery", not relay. Relay is used to indicate passing
> on to another MTA.

And how does it get from the outgoing MTA, to the incoming MTA? Relay.
Thus - an MTA that does not relay, is merely a POP.

btw - it would be more accurate for you to say POP3 Server, because POP
has a very specific tele-communications networking meaning beyond
internet email.

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>> I like the way you wobble back and forth on that.
>>> It's not a realy - except when it is.
>>
>> Nope, I stand that most public MTA's are not relays.
>
> OK, Jerry - but that requires a very wrong interpretation of the word
> "Transfer".
>

No, it doesn't. Transfer can take many forms. Relay is only one of them.

> Seriously - on this I consider myself an honest expert. Back in 95, I
> built the first Fax-Over-IP protocol, as you've heard me say once or
> twice before.
>

Hmmm, you've already shown you don't understand the difference between
"relay" and "delivery", don't know a POP server cannot receive SMTP
email, or an MTA cannot handle POP3 protocol.

> In that effort, I spent a year *constantly* consulting with Marshall
> Rose and he gave me an excellent education on this. If you don't know
> who he is, check the SMTP specification; his name is on it.
>

I think you need to go back to school. I've been setting up MTA's, POP3
servers, etc. for quite a number of years. How many have you set up
from scratch?

> I can't claim his expertise as my own - but when you consider that MTA
> stands for Message Transfer Agent, the truth that it is a relay becomes
> quite self-evident.
>

Obviously. And you obviously can look up MTA in Wikipedia. But you
need to understand what it means.

>
>>> That last, of course, is why I suggested that the OP use an SSL
>>> secured mail relay.
>>
>> Which has absolutely no effect on whether the relay is secure or not.
>> All SSL does is encrypt the data.
>
> Wow - could you BE more self-contradictory?
>

Not at all contradictory. SSL just ensures the data sent between MTA's
is secure, not an MTA itself. The MTA can still be compromised, and if
it is the destination MTA, the data will be available unencrypted.

>
>> When an MTA receives a message and places it in a POP (or IMAP)
>> mailbox, it is called "Delivery", not relay. Relay is used to
>> indicate passing on to another MTA.
>
> And how does it get from the outgoing MTA, to the incoming MTA? Relay.
> Thus - an MTA that does not relay, is merely a POP.
>

Nope. Straight SMTP protocol. There is no no relay involved because
the two communicate directly. Relaying is done through a third party.

> btw - it would be more accurate for you to say POP3 Server, because POP
> has a very specific tele-communications networking meaning beyond
> internet email.

Yes, I know. Lots of terms and acronyms have different meanings when
used in different contexts. This is not a telecommunications newsgroup.

And, POP is also correct. It describes a generic type of protocol. POP3
specifies a specific implementation of that protocol.

And you have a LOT to learn about this subject, Sanders.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Sanders Kaufman wrote:
> C. wrote:
>> On 16 Sep, 21:55, Sanders Kaufman <bu...@kaufman.net> wrote:
>>> RageARC wrote:
>>>> I've made a script that sends mails, and it sends mails correctly for
>>>> gMail, but not for Hotmail. What happens is that on Hotmail the mails
>>>> are not even received! Nor on spam box, nor on inbox.
>> <snip>
>>> It may cost a nickel or two, but sending your mail out through a third
>>> party SMTP server that uses SSL, instead of your hosting providers
>>> default mail relay may allow the mail to go through.
>>
>> ?
>
> If you're on a black-hole list, it's easier to find a new relay than to
> try to fight the most powerful force in the universe.
>

Actually, most blacklists (at least the commonly used ones) will remove
the host within 24 hours of the spam stopping. They understand
sometimes a hosting company gets blind-sided by a spammer, and as long
as the problem is fixed quickly, the server will be removed from the
blacklist quickly.

> If you use SSL to connect to the SMTP relay, your login credentials
> can't easily be "sniffed".
>

But that's not the most common reason for a server getting blacklisted.
And it's also only valid if you have your own MTA (not shared by
anyone else) on your own IP and have it configured correctly.

>
>> Certainly you will have problems sending mail from a known DHCP
>> address (on Unix/Linux try a null mailer going through a registered
>> MX) if you have an MX address on the origin already, make sure you've
>> got a sensible SPF enabled in your DNS.
>
> SPF?
>

I thought you were an expert on this.

Something that's a good concept, but full of holes. It's not widely
used, and probably never will be.

>
>> At the end of the day, though, the Hotmail service is worth exactly
>> what most users pay for it. And don't expect any from them as to
>> why mail gets detected as SPAM.
>
> When I first started participating in Usenet Political discussions, I
> used my hotmail address - then one day I tried to login and got a "go to
> hell, you spammer" denial message. Same thing with Yahoo.
>
> Screw 'em, both.
>

And it can happen on any email you post on usenet.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>>> I like the way you wobble back and forth on that.
>>> It's not a realy - except when it is.
>>
>> Nope, I stand that most public MTA's are not relays.
>
>OK, Jerry - but that requires a very wrong interpretation of the word
>"Transfer".

A typical public MTA that is NOT considered an open relay will
permit mail traffic that is:

(a) destined for mailboxes that it handles (incoming mail from
anywhere is allowed, subject to SPAM filtering). Note that
the mailboxes are NOT necessarily on the same machine. In
large setups the public MTA may be a border MX machine with
few (e.g. "root" only) or no mailboxes and they pass the mail
to the servers with the mailboxes.
or (b) sent in by trusted customers or from trusted locations to the
world (outgoing mail from my customers is allowed). This may
be checked by a number of methods:
(1) Authenticated SMTP, with or without SSL
(2) POP-before-send: you must check your mailbox from the
IP address you are using within X minutes before sending
mail out.
(3) SSL with user certificates
(4) Using extensions to POP3 or IMAP to send mail during
a mail-fetching session.
(5) Allowing any mail from IP blocks owned by the ISP
(6) Combinations of these, such as (5) from DSL or dialup
lines and (1) or (2) from "roaming" customers
(7) There's all sorts of other methods also.

This does not address the subject of SPAM filtering or virus scanning.

Incidentally, there's a subtle difference between "relay" and
"forward". This terminology might not be universal but its in
use at some ISP abuse departments.

Let's suppose that there is a mail service that will accept mail
to me at me@service.com and forward it to any mailbox I designate.
I designate my mailbox at my local ISP, me@isp.com . When someone
does a spam run against the @service.com addresses, service.com may
get accused of being an open relay when it doesn't really deserve
it.

A spammer connects to the service.com mail server and drops off a
penis enlargement ad for me@service.com. Their server transfers it
to the mail server at isp.com, which delivers into the me@isp.com
mailbox. This is a *forward*. The *customer* requested the routing
from service.com to isp.com.

A spammer connects to the service.com mail server and drops off a
penis enlargement ad for you@aol.com. Their server transfers it to
the mail server at aol.com. Unless the spammer had authentication
or permission to use the service.com mail server, this makes it an
open relay. The *spammer*, not the AOL customer, requested the
routing from service.com to aol.com.


>Seriously - on this I consider myself an honest expert. Back in 95, I
>built the first Fax-Over-IP protocol, as you've heard me say once or
>twice before.
>
>In that effort, I spent a year *constantly* consulting with Marshall
>Rose and he gave me an excellent education on this. If you don't know
>who he is, check the SMTP specification; his name is on it.
>
>I can't claim his expertise as my own - but when you consider that MTA
>stands for Message Transfer Agent, the truth that it is a relay becomes
>quite self-evident.
>
>
>>> That last, of course, is why I suggested that the OP use an SSL
>>> secured mail relay.
>>
>> Which has absolutely no effect on whether the relay is secure or not.
>> All SSL does is encrypt the data.
>
>Wow - could you BE more self-contradictory?

SSL encrypts the data so the thief of a customer (using a phony
credit card number) can rip off the thief running the web site
before any other thief (such as the FBI or dishonest ISP employee)
can get to the card number. SSL does not identify the customer to
the web site, unless it insists on user certificates.

It works the same way with email. A spammer can securely shower
the whole internet with penis enlargement ads while making it
difficult for someone tapping the net to see what's in the email
until their copy lands in their mailbox.


>> When an MTA receives a message and places it in a POP (or IMAP) mailbox,
>> it is called "Delivery", not relay. Relay is used to indicate passing
>> on to another MTA.

Many corporate and ISP setups have "border MX machines" running a
MTA which receives the email and passes it on to one of a bunch of
another machines which actually hold the mailboxes. The "border
MX machines" have few or no mailboxes themselves.

>And how does it get from the outgoing MTA, to the incoming MTA? Relay.
>Thus - an MTA that does not relay, is merely a POP.

I suggest not using the abbreviation "POP" to refer to "Point of
Presence" when discussing mail protocols. There's another meaning
for that TLA (And I don't mean Tokyo Law Association). Similarly,
don't use "IP" to mean "Intellectual Property" when discussing TCP
port numbers.

>btw - it would be more accurate for you to say POP3 Server, because POP
>has a very specific tele-communications networking meaning beyond
>internet email.

Gordon Burditt wrote:
>>>> I like the way you wobble back and forth on that.
>>>> It's not a realy - except when it is.
>>> Nope, I stand that most public MTA's are not relays.
>> OK, Jerry - but that requires a very wrong interpretation of the word
>> "Transfer".
>
> A typical public MTA that is NOT considered an open relay will
> permit mail traffic that is:
>
> (a) destined for mailboxes that it handles (incoming mail from
> anywhere is allowed, subject to SPAM filtering). Note that
> the mailboxes are NOT necessarily on the same machine. In
> large setups the public MTA may be a border MX machine with
> few (e.g. "root" only) or no mailboxes and they pass the mail
> to the servers with the mailboxes.

This is not a relay.

> or (b) sent in by trusted customers or from trusted locations to the
> world (outgoing mail from my customers is allowed). This may
> be checked by a number of methods:
> (1) Authenticated SMTP, with or without SSL
> (2) POP-before-send: you must check your mailbox from the
> IP address you are using within X minutes before sending
> mail out.
> (3) SSL with user certificates
> (4) Using extensions to POP3 or IMAP to send mail during
> a mail-fetching session.
> (5) Allowing any mail from IP blocks owned by the ISP
> (6) Combinations of these, such as (5) from DSL or dialup
> lines and (1) or (2) from "roaming" customers
> (7) There's all sorts of other methods also.
>

True, but the majority of the MTA's on the internet are not configured
these ways. Those that are are generally ISP's or shared hosting
companies. And a few are owned by spam filtering companies.

There are many more MTA's out there owned by individuals, companies,
etc. which only match (a).

> This does not address the subject of SPAM filtering or virus scanning.
>
> Incidentally, there's a subtle difference between "relay" and
> "forward". This terminology might not be universal but its in
> use at some ISP abuse departments.
>
> Let's suppose that there is a mail service that will accept mail
> to me at me@service.com and forward it to any mailbox I designate.
> I designate my mailbox at my local ISP, me@isp.com . When someone
> does a spam run against the @service.com addresses, service.com may
> get accused of being an open relay when it doesn't really deserve
> it.
>
> A spammer connects to the service.com mail server and drops off a
> penis enlargement ad for me@service.com. Their server transfers it
> to the mail server at isp.com, which delivers into the me@isp.com
> mailbox. This is a *forward*. The *customer* requested the routing
> from service.com to isp.com.
>
> A spammer connects to the service.com mail server and drops off a
> penis enlargement ad for you@aol.com. Their server transfers it to
> the mail server at aol.com. Unless the spammer had authentication
> or permission to use the service.com mail server, this makes it an
> open relay. The *spammer*, not the AOL customer, requested the
> routing from service.com to aol.com.
>

Yes, I am quite aware of the difference between relaying and forwarding.

>
>> Seriously - on this I consider myself an honest expert. Back in 95, I
>> built the first Fax-Over-IP protocol, as you've heard me say once or
>> twice before.
>>
>> In that effort, I spent a year *constantly* consulting with Marshall
>> Rose and he gave me an excellent education on this. If you don't know
>> who he is, check the SMTP specification; his name is on it.
>>
>> I can't claim his expertise as my own - but when you consider that MTA
>> stands for Message Transfer Agent, the truth that it is a relay becomes
>> quite self-evident.
>>
>>
>>>> That last, of course, is why I suggested that the OP use an SSL
>>>> secured mail relay.
>>> Which has absolutely no effect on whether the relay is secure or not.
>>> All SSL does is encrypt the data.
>> Wow - could you BE more self-contradictory?
>
> SSL encrypts the data so the thief of a customer (using a phony
> credit card number) can rip off the thief running the web site
> before any other thief (such as the FBI or dishonest ISP employee)
> can get to the card number. SSL does not identify the customer to
> the web site, unless it insists on user certificates.
>
> It works the same way with email. A spammer can securely shower
> the whole internet with penis enlargement ads while making it
> difficult for someone tapping the net to see what's in the email
> until their copy lands in their mailbox.
>

I never claimed otherwise. All I said was that SSL encrypts the data
while it was being sent. It can be found in decrypted form on both ends
of the link.

>
>>> When an MTA receives a message and places it in a POP (or IMAP) mailbox,
>>> it is called "Delivery", not relay. Relay is used to indicate passing
>>> on to another MTA.
>
> Many corporate and ISP setups have "border MX machines" running a
> MTA which receives the email and passes it on to one of a bunch of
> another machines which actually hold the mailboxes. The "border
> MX machines" have few or no mailboxes themselves.
>

True, but this is going to an intranet, as I mentioned earlier. I'm
talking about internet relays.

>> And how does it get from the outgoing MTA, to the incoming MTA? Relay.
>> Thus - an MTA that does not relay, is merely a POP.
>
> I suggest not using the abbreviation "POP" to refer to "Point of
> Presence" when discussing mail protocols. There's another meaning
> for that TLA (And I don't mean Tokyo Law Association). Similarly,
> don't use "IP" to mean "Intellectual Property" when discussing TCP
> port numbers.
>
>> btw - it would be more accurate for you to say POP3 Server, because POP
>> has a very specific tele-communications networking meaning beyond
>> internet email.
>
>

I never referred to POP meaning "Point of Presence". Every time I used
it was 'Post Office Protocol". And when I referred to IP, I was talking
about Internet Protocol. Nothing different.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================