spf-discuss
[Top] [All Lists]

RE: Extreme times call for extreme measures?

2004-10-07 06:06:38
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Hector 
Santos
Sent: Wednesday, October 06, 2004 10:27 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Extreme times call for extreme measures?



----- Original Message -----
From: "Theo Schlossnagle" <jesus(_at_)omniti(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Cc: "Theo Schlossnagle" <jesus(_at_)omniti(_dot_)com>
Sent: Wednesday, October 06, 2004 9:45 PM
Subject: Re: [spf-discuss] Extreme times call for extreme measures?



On Oct 6, 2004, at 9:31 PM, Hector Santos wrote:
Yes, this is a common thing.  In an age when most
direct-to-MX spam comes from broadband zombies, any PTR
hostname that contains its IP address is automatically
suspect.  Being a subdomain of a known broadband provider is
confirmation.

Yeah, but I would wish if they would delay the PTR check
to see if the
user
is roaming and is going to login with ESMTP AUTH.  If no
login, then go
ahead and do whatever.

Many do this.  It is quite easy to do with most OS MTAs
(and commercial
ones too).

Very few MTAs will use SMTP AUTH to transport mail -- you
really have
to customize them to do that.

We are talking about MUA to MSA which indeed ESMTP AUTH is
quite popular and
a growing requirement.

MTA routers are normally already secured using traditional IP
allow tables.

Agreed



Technically, until the SMTP specs are refined,  the LOGIN check
approach is
more "compatible" with SMTP standards.  The "immediate" reject is
somewhat
against the specs.

It isn't really against the specs.

Per specifications all systems must accept mail for final
destinations so
under the current specification, authentication of any kind is not a
requirement.  Of course, that is the exploitation and the essence of
the spam/spoof problem today.

Agreed


Therefore, per specification, until the receiver knows who
the connection
is, it is going against the specification because it doesn't
know if its
going to be an authorized session or non-required authorized final
destination session.  Never mind that RFC 2821 says that mail

It does know port 25 connection is NOT authorized if authorized connections 
only come in on, say,
port 587, which would be per spec.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085


should not be
rejection if HELO fails:

RFC 2821 4.1.4 Order of Commands

   An SMTP server MAY verify that the domain name parameter
in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about
verification
   failure is for logging and tracing only.

Of course, between you, I and the fence post,  I am strong
believe that
ultimate solution to the spam issue will be based on using
enforceable SMTP
compliancy.  This is what we did for system.

Note: I am not 100% against a PTR check. Just that they
should "fit it" into
the current scheme of things so that it isn't so drastic.
The hurt users
are the legit fee-paying roaming ISO user who might be using
an machine that
isn't PTR ready and even if it was,  doesn't really solve the
problem?  I
don't think so.   However, allowing the user to authenticate
will tell the
ISP the user is legit.

Anyway, that's my view.  Thanks

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in
Atlanta features SPF and Sender ID.
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com