You are here: Re: Send a mail without going to spam « PHP Programming Language « IT news, forums, messages
Re: Send a mail without going to spam

Posted by Jerry Stuckle on 09/19/07 18:14

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
==================

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация