On Thu, 2004-07-29 at 08:53, Andrew Newton wrote:
On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote:
There is no such thing as an RFC2821.TO identity.
Then we needn't worry about using a valid list of users when doing
Sender-ID or SPF checks then. :)
On Jul 28, 2004, at 6:06 PM, Douglas Otis wrote:
SPF offered some relief, if the MTA creating the bounce checked the
destination domain records for valid sources of the message. This is
lost with Sender-ID. A solution for this problem could be found
through a combination of SPF and BATV, where BATV is less
disruptive. SPF accommodates an address based white-list, but such
a list would be of less use, with CSV offering names.
I was under the assumption that BATV was a much better fit with domain
keys than with SPF. Actually, I have no idea what it has to do with
SPF at all. BATV is an interesting idea.
BATV uses DNS DomainKeys for a method that could allow the bounce to be
prevented in much the same manner as SPF would have done. The
difference between SPF and BATV would be the method used to authenticate
the originating domain. SPF would use a number of DNS TXT records to
compile a "comprehensive" or "closed" list of addresses of all outbound
SMTP servers sending messages using the domain of RFC 2821 MAIL FROM to
prevent the bounce. BATV could authenticate the domain using a DNS
DomainKey to prevent the bounce. BATV provides no assurance of the RFC
2822 From, nor does SPF.
On Jul 29, 2004, at 3:19 AM, Douglas Otis wrote:
Sender-ID checks the Purported Responsible Address (PRA) and may not
include the RFC 2822 From. Sender-ID does not check the RFC 2821 RCPT
TO or the RFC 2822 To. Such checks are done independently.
I'm glad there's agreement on this. :)
The scenario described was to illustrate a generation of a bounce
(resending of the message to the RFC 2821 MAIL FROM) rather than an
immediate message rejection with a 5xx error. The bounce occurs, in
this case, when the mail is being relayed by an MTA that does not have
a list of valid users, but is only checking the right hand side of
the RFC 2821 RCPT TO address. If the message is initially accepted
and then the user is later discovered not valid, the message becomes
bounced.
I understand the scenario. And I keep asking, "why not just do a
Sender-ID (or SPF) check and REJECTION at the first MTA"? And you keep
saying, "It doesn't have the list of valid users." And I keep asking,
"what does a list of valid users have to do with a Sender-ID or SPF
check?"
I attempted to explain this in the following two sentences.
Acceptance does not require a full rating from Sender-ID, and may not
include a full set of other checks at that time. Sender-ID acceptance
could be achieved using a domain with either none, open, owned, or
borrowed records.
The spammer only needs to have the message accepted by the Sender-ID
check. The rating for the check does not matter, provided the message
is accepted. This could mean the domain claimed by the PRA which would
be:
First RFC 2822.Resent-Sender else
First RFC 2822.Resent-From else
Singular RFC 2822.Sender else
Singular RFC 2822.From
and receives a Sender-ID rating:
Pass (+)
Neutral (?)
SoftFail (~ may accept messages)
TempError (transient DNS or format error, may accept messages)
PermError (unrecoverable format error, may accept messages)
None (no records)
Those publishing records may include "+all" or "?all" as a method allow
their record set to be less than comprehensive. Creating a
comprehensive record set could be daunting, with a limit of just 100 or
so DNS lookups with just 10 calls to Check_Host(). : )
If the bouncer has published their SPF record, then the bounce may
receive a Pass(+) rating. : (
huh? what?
A relay MTA may also opt to turn off Sender-ID
channel checks.
Well, that is between you and the people you list in the target of your
MX. A relay MTA may also opt to block 0/0, but that's no fault of
Sender-ID or SPF.
No. Bounce traffic is from a third-party beyond the control of the MTA
receiving the bounce. This is not between related parties.
Are you trying to say that Sender-ID checks will only be one part of a
spam-filter evaluation that can only take place on the delivery MTA?
No. The Sender-ID rating system directs mail into different folders
(rat-holes), and leaves to the end-user the task of sorting and
deleting. The goal should be to have the message either rejected
outright or placed into the inbox. If there is a problem, it can be
discovered and resolved, at the expense of the sender.
The Sender-ID approach seriously degrades reliability of mail in a
systemic fashion, and puts a much greater burden onto the recipient. It
does not really stop phishing, bounces, or spoofing. It does not
identify the domain responsible for the introduction of the abuse. It
does not allow a means to control such introduction. It does break
forwarding. It does break mail "exploders". It does cause users to
change their mail address. It does cause users to expose more of the
mail addresses. It does put mail and DNS at risk.
If so, isn't this your responsibility to handle properly since step 6
of the PRA says "SHOULD" reject (meaning, if you didn't, you really
ought to know what you are doing).
That would be for resolving the PRA. If a spammer can't get past the
test of creating a valid header, then it should be rejected. I would
not expect the learning curve to be all that steep however, for this
test to stop that much abuse.
Imagine how credit cards would be handled, if there were no means to
authenticate the identity of the person presenting the card. Imagine
the amount of fraud there would be, if were no accreditation system.
Why dream up methods to sort fraud? Stop it! Verify the name of the
sending domain. Remember that domain if there was fraud. Take action
based upon the history of that name. An accreditation service could
make this process simple, but an MTA being administered with strict
policies can make a significant reduction in this mess by just creating
a history based upon names. No name or no history, offer only
constrained service to limit damage. If there was damage, remember it
or report it to the accreditation system.
-Doug