From: Jim Lyon
Sent: August 24, 2004 5:34 PM
Draft marid submitter states in the Introduction on page 2:
Deriving the purported responsible domain from RFC 2821
data has the advantage that validation can be performed
before the SMTP client has transmitted the message body.
If spoofing is detected, then the SMTP server has the
opportunity, depending upon local policy, to reject the
message before it is ever transmitted."
However draft marid core states in the Negative problem
statement at page 2:
Following are several alternate questions, which this
specification makes no attempt to answer:
1. Is the host at a particular IP address authorized to
act as an SMTP client?
2. Is an SMTP client authorized to use a particular
domain name in its SMTP EHLO command?
3. Is an SMTP client authorized to use a particular
email address in an SMTP "MAIL FROM:" command?
4. Was a message really authored by who it claims to be
authored by?
The point being as noted by Chris Haynes in the thread
"What Meng Said" where he wrote:
Meng,
Please may I ask a brutally simple question.
I think it is generally agreed that where MAIL-FROM == PRA
any decision is based on the PRA.
My question below applies only to those messages in which
the domain of the MAIL-FROM is different from the domain of
the PRA.
Where, in the collection of drafts issued on Friday, does
Sender-ID refer to the rejection of a message as a result
of evaluating the record associated with its MAIL-FROM
domain?
Chris Haynes
http://www.imc.org/ietf-mxcomp/mail-archive/msg03306.html
To which Meng responded:
Sender ID as currently specified doesn't do that.
If people want the MAIL FROM to play a role in Sender ID,
they should say so. If they do not say so, the working
assumption is that nobody cares.
I personally think that if the PRA lookup returns "none" or
"unknown", MAIL FROM should be checked, and if that test
returns "fail" then the message should be rejected.
http://www.imc.org/ietf-mxcomp/mail-archive/msg03324.html
- and my follow up message -
http://www.imc.org/ietf-mxcomp/mail-archive/msg03339.html
I am speaking of this issue, which in turn includes the
concern raised by Nate Leon when he wrote in part:
For completeness, here is another example of the concern:
MAIL FROM:<> // don't care
RCPT TO:<valid-recipient(_at_)xxxxxxxxxxx>
DATA
Subject: update your account info Resent-From:
JoePhisher(_at_)xxxxxxxxxxxxxxxx // valid domain
authenticated by MARID ...
From: account-services(_at_)xxxxxxxxxxxx // Spoofed domain,
displayed by the MUA To:
valid-recipient(_at_)xxxxxxxxxxx // bummer for you
... Are we really going to RFC with this issue left
open?
http://www.imc.org/ietf-mxcomp/mail-archive/msg03372.html
Harry Katz's responses:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03375.html
- and -
http://www.imc.org/ietf-mxcomp/mail-archive/msg03416.html
and my message in response:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03443.html
Also see the following three message:
My message found at:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03417.html
- and -
Daryl Odnert's response:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03421.html
- and -
My reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03458.html
These messages reflect the deployment issues I am raising
with marid-protocol/marid-core and which remain outstanding.
Please also note the last statement from Chris Haynes in
his most recent message:
And incorporating the tests & semantics developed in SPF
would result in even fewer bounces - and totally eliminate
the situations which concern me.
Trusting this makes my position clearer.
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004