On Mon, 29 Jan 2007, Stuart D. Gathman wrote:
On Mon, 29 Jan 2007, Dick St.Peters wrote:
John Q Spammer owns johnsspamdomain.com, so the name-->IP resolution
is under his control. He connects to my mail server with IP a.b.c.d
and gives HELO name "mail.johnsspamdomain.com". I check what that
resolves to and find it resolves to a.b.c.d. Then I check what
a.b.c.d reverse resolves to and get port6.box4.dialup.isp.pl. Guess
what I use the PTR for.
That is fine, but PTR did *not* help you authenticate connection.
It was a genuine authentic johnsspamdomain.com HELO name - and you
knew that without checking PTR. Any reputation points can
properly be assigned to johnsspamdomain.com:HELO. It was not forged.
I am not complaining about using PTR as part of a spam detection
heuristic. I do it myself. I am complaining about using PTR to
*authenticate* the connection.
spam != forgery
In case of SPF checks the forgery is considered to be when client
is doing something again specified SPF policy, i.e. SPF really
just says if client is authorized to be using email parameters
the way they are - if they are not it is assumed to be bad client
(i.e. most likely forgery but it may well be just misuse of the
parameters by some remote user or misconfig).
Checking PTR allows to verify if the client is authorized to be
doing SMTP connections as far as owner of the ip space sees it.
This is pretty similar to EHLO/HELO check as it checks if an
SMTP client with specified HELO name is authorized to be using
specified ip address. Note that they are not equivalent.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735