draft-schlitt-spf-classic-01.txt

[Douglas Otis]

My previous message was to explain why the MARID reflector is being used
for these comments. SPF could offer white-listing utility, provided
there is consensus on the record's scope. Such use requires that this
scope be defined, or not used as a basis for accruing reputations. Of
course, this would make SPF useless for anything other than
white-listing. Nor would I trust anyone to honor such exclusion.
However, SPF proponents still insist this mechanism is fair with respect
to assessing reputations. I say it is fundamentally flawed, as
assumptions of assured identifiers place domain owners in serious
jeopardy.

The email provider must be held accountable in any meaningful approach
for abating abuse. However, SPF avoids such accountability. A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners. Only signatures offer domain owners a
modicum of control and oversight in their pursuit of protecting their
domain's reputation.


Be that as it may, I see this effort as reducing the harm created by
SPF. : <

1. Introduction
,----
| The current e-mail infrastructure has the property that any host
| injecting mail into the mail system can identify itself as any domain
| name it wants. Hosts can do this at a variety of levels: in
| particular, the session, the envelope, and the mail headers. While
| this feature is desirable in some circumstances, it is a major
| obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
| Furthermore, many domain name holders are understandably concerned
| about the ease with which other entities may make use of their domain
| names, often with malicious intent.
'----

This paragraph lists many different identities that could be used to
identify the sender, and implies any could be examined to discover
possible server authorization. As just mentioned, some still consider
this provides a method for performing sender authentication. These same
individuals will happily block any such domains, once they are assumed
abusers. After all, abusers can and will also publish SPF records.

A disagreement regarding which of these identifiers MUST be assured by
the sending server (to protect their client's reputation) occurs within
this draft and the draft-lyon-senderid-core-01.txt. It is amazing that
this happens even though both of these drafts share the same author. Of
course, protecting one's reputation depends upon this important detail.
However this draft only defines use of MAILFROM within the message, and
ignores this rather serious concern. This is not FUD, this is just
F. : )

Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm. This harm could originate from a Zombied computer of such
a customer. The abuser may utilize SPF records to obfuscate where the
message originates to prolong their success, when seeing such messages
are not blocked by the sending server.

SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender. (I want to
say based upon "Sender Assumptication.") How can the domain owner
restore the use of their domain, after their provider naively believes
they can assume how a record will be interpreted which has an undefined
scope? Wouldn't providers be negligent when advising the use of SPF and
not making strict PRA validations? Publication of a dummy record for
PRA, which may cause loss of messages, does not seem a satisfactory
solution, as provided in the Sender-ID draft.



10.2. SPF-Authorized E-Mail May Be UBE
,----
| The "MAIL FROM" and "HELO" identity authorizations must not be
| construed to provide more assurance than they do. It is entirely
| possible for a malicious sender to inject a message using their own
| domain in the identities used by SPF, to have that domain's SPF
| record authorize the sending host, and yet the message content can
| easily claim other identities in the headers. Unless the user or the
| MUA takes care to note that the authorized identity does not match
| the other more commonly-presented identities (such as the From:
| header), the user may be lulled into a false sense of security.
'----

An interesting, albeit fuzzy, warning indeed. Add another warning of a
similar nature. Because there may be an assumption made regarding
server "authorization" (even potentially a neutral authorization) being
equivalent to sender "authentication," your domain may be attributed for
abuse which forges any identifiers other than MAILFROM. Microsoft
describes a PRA process based upon this specific SPF record, used in
conjunction with SmartScreen, for example. This creates the potential
for serious harm to the domain owner's reputation, when providers ignore
potential PRA conflicts.

Add a warning that examination of the PRA is REQUIRED for cases where
the recipient uses draft-lyon-senderid-core-01.txt, which only utilize
the record syntax described in this draft. Publishing an SPF record
will not ensure which identifier will be held accountable for abuse. If
your email-provider does not license the PRA algorithm, there should be
no expectation that your domain's reputation is being protected.

I'll be happy to agree with Carl about the white-listing utility of an
SPF record. To repair this draft, there appears little choice, but to
adopt the later version of the SPF record which includes the scope of
the identifiers assured by the sender. That was the reason for
including scope in the first place. Ignoring this issue would be
ignoring a rather big elephant in the room. It would also represent
serious negligence on the part of the provider.



10. Security Considerations
,----
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries. For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory
| usage, and DoS attacks.
|
| MTAs or other processors MAY also impose a limit on the maximum
| amount of elapsed time to evaluate check_host(). Such a limit SHOULD
| allow at least 20 seconds. If such a limit is exceeded, the result
| of authorization SHOULD be "TempError".
'----

With this draft mandating more than one hundred DNS lookups, this raises
a concern regarding how the 20 second time limit is employed. A local
recursive DNS resolver may act as a UDP amplifier. Congestion avoidance
depends upon the application making the requests to wait, in order to
maintain stability.

There should be some language that warns against doing these many
lookups in parallel, and simply timing out the effort to resolve server
authorization for a particular message. If parsing routines have not
made these provisions, then setting up a two-tier DNS resolver where the
Internet facing DNS resolver is not recursive and is rate limited on
port 53, could offer a solution.

There should also be a warning about acceptance of duplicate records.
The same two-tier approach would offer protection when older DNS
resolvers are being used that do not ensure replicate lookups are
prevented.

-Doug

[Julian Mehnle]

Thanks for your review.

Post by Douglas Otis
The email provider must be held accountable in any meaningful approach
for abating abuse. However, SPF avoids such accountability. A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.

Why do you think ISPs must be held accountable instead of domain owners?

Post by Douglas Otis
Only signatures offer domain owners a modicum of control and oversight in
their pursuit of protecting their domain's reputation.

Why?

Post by Douglas Otis
1. Introduction
[...]
Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm.

If you are talking of cross-user forgery, see SPF, section 10.4[1]. This
isn't something that can generally be solved by an authorization protocol
that works with a granularity of IP addresses.

If you are talking of something else, I don't know what it is.

Post by Douglas Otis
This harm could originate from a Zombied computer of such a customer.
The abuser may utilize SPF records to obfuscate where the message
originates to prolong their success, when seeing such messages are not
blocked by the sending server.

How could SPF records be used to "obfuscate" a message's origin? The last
time I looked, SPF didn't suppress the generation of "Received:" headers.

Post by Douglas Otis
SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender.

So what? Receivers are already doing the same with IP address white- and
black-lists. The world has not gone up in flames, though.

Post by Douglas Otis
How can the domain owner restore the use of their domain, after their
provider naively believes they can assume how a record will be
interpreted which has an undefined scope?

(I assume you aren't implying that the concepts of accountability and
reputation are fundamentally flawed.)

There are no SPF records with an undefined scope. If, for v=spf1 records,
receivers choose to apply Sender-ID's inconsistent scope definition (PRA)
over that of SPF itself, is it SPF's fault?

Have you complained already to Microsoft and the IESG about Sender-ID
redefining v=spf1 records? If not, why do you keep bringing up this issue
here? To say that even though this inconsistency is not SPF's fault,
another draft can always be employed to destroy its usefulness?

What if I submitted a draft to the IETF that conflicted with the DomainKeys
specification? Would that make DomainKeys useless (or harmful)?

Post by Douglas Otis
10. Security Considerations
[...]
With this draft mandating more than one hundred DNS lookups,

The SPF specification does not "mandate more than one hundred" DNS lookups.
It mandates that a receiver must be prepared to perform at most 111 DNS
lookups. This does not mean that the usual case is anywhere near that.

Post by Douglas Otis
this raises a concern regarding how the 20 second time limit is employed.
A local recursive DNS resolver may act as a UDP amplifier. Congestion
avoidance depends upon the application making the requests to wait, in
order to maintain stability.
[...]

This sounds like a valid concern.

Post by Douglas Otis
There should also be a warning about acceptance of duplicate records.

What do you mean by "duplicate records"?

Again, thanks for your review.

Julian.

References:
1.
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#cross-user-forgery

[Douglas Otis]

Post by Julian Mehnle

Post by Douglas Otis
The email provider must be held accountable in any meaningful approach
for abating abuse. However, SPF avoids such accountability. A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.

Why do you think ISPs must be held accountable instead of domain owners?

Abating abuse requires diligence. This diligence involves the
monitoring of servers. To protect the privacy of other customers, much
of an MTA server's operation remains hidden from the domain owner, who
is often just one of many typical customers. With SPF reliance on the
mailbox-domain, the server's administrator remains anonymous. Negligent
server operation will not directly impact the administrator, but instead
impacts the domain owner. A reputation system should hold accountable
those who are expected to maintain diligence in respect to security,
access, and operation. Holding an innocent, feckless party accountable
is simply an unfair practice. Dare I say even foolish?

By the time a domain owner is made aware that volumes of abuse has
emerged from some SPF authorized server, forging their mailbox-domain in
some unexpected header, the reputation of their domain may have become
unsuitable for email. The means to recoup their reputation in this
situation may not be practical.

The domain owner may be innocent. They may also view their domain as
highly valuable. They may also be required to seek expensive legal
avenues to uncover the cause of their dilemma. With SPF building upon a
filtering paradigm, there may be no outward indication their messages
are being silently dropped or placed into junk folders either. It is
not clear how the domain owner will recover reliable use of their email
domain after publishing SPF and then being exploited.

This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse. Nevertheless, abating abuse requires holding
administrators accountable and ensuring they stay on top of security,
access, and operational issues. A reputation scheme MUST identify the
source of abuse, and not the "assumed" source of abuse. A reputation
scheme must hold those responsible, accountable. SPF fails badly on
both of these issues. It is folly to think SPF will improve the
integrity of email or diminish the rate of abuse. A reputation scheme
based upon SPF authorization is certain to dramatically reduce email's
integrity for the majority of domain owners.

Post by Julian Mehnle

Post by Douglas Otis
Only signatures offer domain owners a modicum of control and oversight in
their pursuit of protecting their domain's reputation.

Why?

By retaining a signature operation within their administrative control,
the domain owner would have far greater control over the fate of their
domain's reputation. They could utilize the services of an email
provider to relay email from a dynamic location, without fear other
abusive messages may be confused as being from them. If their relay
provider was lax at security or preventing abuse, the domain owner can
seek a different provider to rectify any resulting problems.

You should put yourself into your customer's position. Proclamations
that with SPF, some domain can not be forged are specious. This of
course assumes closed-ended list, where the domain owner maintains
exclusive access to their servers. Closed-ended lists are not
practical, nor do most domain owners manage their own MTAs with
exclusive access.

A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.
Especially an email provider with dubious motives asking them to publish
SPF records. How on Earth can publishing an SPF record be in the
interest of the domain owner, after Microsoft proclaims server
authorization is the same as sender authentication?

A DomainKeys signature associated with the Sender header allows the
provider to accept accountability for their customers, without mandating
their customers change their email addresses or publish DNS records.
The provider could also offer to relay messages already signed by their
customers as well. Either of these scenarios would be fair.

With prior knowledge of the sender, perhaps in the case where an SPF
record is being used to establish a white-list, SPF could offer utility.
White-listing may be practical for typical bulk emailers, but not for
the majority of email domains. However, DomainKeys could supplant
reliance upon white-listing, without the overhead needed to maintain a
complex database that may create problematic overlaps.

Post by Julian Mehnle

Post by Douglas Otis
1. Introduction
[...]
Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm.

If you are talking of cross-user forgery, see SPF, section 10.4[1]. This
isn't something that can generally be solved by an authorization protocol
that works with a granularity of IP addresses.

You misunderstood the concern. An email provider likely handles
customers using many different mailbox-domains. Yes, there could be
cross-user forgery within a domain, but that was not the concern. There
could also be cross-domain forgery. The provider is expected to make
assurances that some range of domains is permitted specifically for
those provided access to the MTA. If the provider does not properly
authenticate the user (some still exchange passwords in the clear), or
does not evaluate the PRA, the domain owner is placed at risk by
publishing SPF records. The sender does not know what the recipient
uses to base their reputation assessments. Someone can get seriously
hurt heedlessly publishing SPF.

Post by Julian Mehnle
If you are talking of something else, I don't know what it is.

Post by Douglas Otis
This harm could originate from a Zombied computer of such a customer.
The abuser may utilize SPF records to obfuscate where the message
originates to prolong their success, when seeing such messages are not
blocked by the sending server.

How could SPF records be used to "obfuscate" a message's origin? The last
time I looked, SPF didn't suppress the generation of "Received:" headers.

Anyone that utilizes a large provider and publishes an SPF record that,
in effect, proclaims such use, could enable an abuser to send from the
correct server, while still lying about who they are. SPF does not
prevent this problem. SPF requires assumed checks that may or may not
be performed. In fact, some of these checks may require a license. : (

The abuser may wish to play this game until they have scorched the
reputation of that domain, before usurping the identity of the next
available victim, all while thanking SPF for making their fun possible.

Post by Julian Mehnle

Post by Douglas Otis
SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender.

So what? Receivers are already doing the same with IP address white- and
black-lists. The world has not gone up in flames, though.

Quite typically, providers that employ a black-hole listing service,
will indicate the website of this service in the error message returned
in the session refusal. The person sending the message can opt to
immediately try a different provider to send their message. They may
also elect to complain to the black-hole listing service that indicated
the MTA they utilized is not properly administered.

Perhaps the server administration permitted access to the wrong person,
perhaps they accidentally enabled an open-proxy in their network,
perhaps they even allowed an open-relay. Whatever the problem, the
sender often knows where to go for restitution. As SPF is intended to
assist the filtering of messages, filtering often employs a practice of
placing uncertain results into a junk folder. With SPF, there are many
shades of gray. : (

Post by Julian Mehnle

Post by Douglas Otis
How can the domain owner restore the use of their domain, after their
provider naively believes they can assume how a record will be
interpreted which has an undefined scope?

(I assume you aren't implying that the concepts of accountability and
reputation are fundamentally flawed.)

The assumption that a mailbox-domain can be authenticated without the
use of a signature is fundamentally flawed. Server authorization is far
too weak to base a presumption of having authenticated the sender.
Server authorization in the manner of SPF also wrecks havoc on email's
architecture. There is no reason for this, when signatures require less
effort and create less collateral damage.

Post by Julian Mehnle
There are no SPF records with an undefined scope. If, for v=spf1 records,
receivers choose to apply Sender-ID's inconsistent scope definition (PRA)
over that of SPF itself, is it SPF's fault?

So are you going to tell a 900 pound gorilla they are wrong? In the
end, the gorilla will have their way with you. ; )

Post by Julian Mehnle
Have you complained already to Microsoft and the IESG about Sender-ID
redefining v=spf1 records? If not, why do you keep bringing up this issue
here? To say that even though this inconsistency is not SPF's fault,
another draft can always be employed to destroy its usefulness?

Strange, I see the same author on both drafts? Who's fault is that?
Depreciate the use v=spf1 to be assured of avoiding this serious
conflict.

Post by Julian Mehnle
What if I submitted a draft to the IETF that conflicted with the DomainKeys
specification? Would that make DomainKeys useless (or harmful)?

What patent licensing restrictions would you impose? Are you large
enough to make your claims a serious concern? Would you be asking
domain owners to fall into a trap, which over time as a ubiquitous
reputation program is applied, necessitates domain owners find providers
that license your scheme?

Post by Julian Mehnle

Post by Douglas Otis
10. Security Considerations
[...]
With this draft mandating more than one hundred DNS lookups,

The SPF specification does not "mandate more than one hundred" DNS lookups.
It mandates that a receiver must be prepared to perform at most 111 DNS
lookups. This does not mean that the usual case is anywhere near that.

Odd, but I see a required minimum as a mandate, and 111 is more than
100. If there are on average 5 queries created for every lookup, this
could mean 555 queries are required to resolve a server's authorization
for a single message.

Post by Julian Mehnle

Post by Douglas Otis
this raises a concern regarding how the 20 second time limit is employed.
A local recursive DNS resolver may act as a UDP amplifier. Congestion
avoidance depends upon the application making the requests to wait, in
order to maintain stability.
[...]

This sounds like a valid concern.

Post by Douglas Otis
There should also be a warning about acceptance of duplicate records.

What do you mean by "duplicate records"?

DNS transactions are only protected by a 16 bit integer. Often routines
utilize the UDP port to multiplex results. The sequence of Domain Name
Server queries dictated by an SPF script may expose the port being used.
There is also a further risk that replicate queries, as possible with
Bind 8 for example, may again greatly increase the chances of guessing a
transaction. As this can be caused to happen repeatedly, success does
not need to be 100% for this to be a concern. The two-tier
recursive/non-recursive resolver was suggested as a defensive measure.
It just seems more informative than recommending DNS paranoia.


-Doug

[Terry Fielder]

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
The email provider must be held accountable in any meaningful approach
for abating abuse. However, SPF avoids such accountability. A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.

Why do you think ISPs must be held accountable instead of domain owners?

Abating abuse requires diligence. This diligence involves the
monitoring of servers. To protect the privacy of other customers, much
of an MTA server's operation remains hidden from the domain owner, who
is often just one of many typical customers. With SPF reliance on the
mailbox-domain, the server's administrator remains anonymous. Negligent
server operation will not directly impact the administrator, but instead
impacts the domain owner. A reputation system should hold accountable
those who are expected to maintain diligence in respect to security,
access, and operation. Holding an innocent, feckless party accountable
is simply an unfair practice. Dare I say even foolish?
By the time a domain owner is made aware that volumes of abuse has
emerged from some SPF authorized server, forging their mailbox-domain in
some unexpected header, the reputation of their domain may have become
unsuitable for email. The means to recoup their reputation in this
situation may not be practical.

Interesting so if SPF fails then SPF will fail.

I say this because the only way the domain owners reputation could have
gotten tarnished was if either:
1) they did not implement SPF to protect forgery of their domain
OR
2) they did implement SPF, and it failed to protect the forgery of
their domain

SPF cannot be help responsible for #1

#1 can only happen if SPF doesn't work, but if SPF doesn't work then all
this is moot.

Perhaps Doug, you are not talking about SPF, because "some unexpected
header" sounds an awful lot like you are referring to the la-la
dreamland that is PRA.

And SPF is *not* PRA. Please don't confused between PRA and SPF (no
matter what Meng has on the damn pobox website).

Post by Douglas Otis
The domain owner may be innocent. They may also view their domain as
highly valuable. They may also be required to seek expensive legal
avenues to uncover the cause of their dilemma. With SPF building upon a
filtering paradigm, there may be no outward indication their messages
are being silently dropped or placed into junk folders either.

*sigh*

PRA may do silent dropping of email after acceptance..

SPF does MTA time rejection, so the sending MTA *must* know that the
email was undeliverable, which guarantees all real, legit connecting
MTA's get a clear rejection on the delivery status.

SA is the only major filtering that uses SPF after the fact, and even a
FAIL scores less then 1 (0.8 something by default) and SA recommends not
rejecting emails that score less than 5-10, then SPF unto itself cannot
be what caused the rejection after acceptance. Something else scored
the other 4-9 points that were need to cause the email to be rejected by SA!

So don't say SPF causes silent dropping of email, its simply not true.
Certainly not in the recommended use of SPF (MTA time rejection) and not
even in the common not recommended use of SPF (SA).

Post by Douglas Otis
It is
not clear how the domain owner will recover reliable use of their email
domain after publishing SPF and then being exploited.

Domain owners can be exploited if they don't publish SPF, nothing
changes by publishing SPF except, if SPF really does work (as time has
shown once forwarders are fixed), SPF may prevent forgery that is the
exploitation that could have resulted in bad reputation.

Post by Douglas Otis
This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse.

SPF is not ignoring concerns. The concerns you have stated are either
unfounded or apply to PRA, not SPF.

Post by Douglas Otis
Nevertheless, abating abuse requires holding
administrators accountable and ensuring they stay on top of security,
access, and operational issues.

Are you suggesting every MTA operator review all inbound email for
forgery/spam/viruses and do something with the ones that are bad? Glad
I am not paying that bill.

Post by Douglas Otis
A reputation scheme MUST identify the
source of abuse, and not the "assumed" source of abuse.

SPF is not a reputation scheme.

SPF is a means to make reputation schemes accurate by preventing forgery.

Post by Douglas Otis
A reputation
scheme must hold those responsible, accountable. SPF fails badly on
both of these issues.

No, it doesn't. A reputation scheme allows domains to obtain
credibility (or not) based on what the domain has done in the past.

SPF simply improves the ability for reputation schemes to be accurate by
preventing forgeries from affecting the reputation database.

Post by Douglas Otis
It is folly to think SPF will improve the
integrity of email or diminish the rate of abuse. A reputation scheme
based upon SPF authorization is certain to dramatically reduce email's
integrity for the majority of domain owners.

I would love to see your facts, or testing, to justify this statement.
Sounds like FUD.

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
Only signatures offer domain owners a modicum of control and oversight in
their pursuit of protecting their domain's reputation.

Why?

By retaining a signature operation within their administrative control,
the domain owner would have far greater control over the fate of their
domain's reputation.

Smells like you want to sell domain owners (or their ISP/MSP) something.
A certificate perhaps? At least now I know your motivation for
attacking SPF.

Post by Douglas Otis
They could utilize the services of an email
provider to relay email from a dynamic location, without fear other
abusive messages may be confused as being from them.

Thank you for endorsing the use of SPF (because that is what SPF does,
only without the need for MUA upgrades to check signatures, and no need
for buying certificates).

Post by Douglas Otis
If their relay
provider was lax at security or preventing abuse, the domain owner can
seek a different provider to rectify any resulting problems.

Which is a good idea no matter what security protocols one implements
(or not) for their domain. Hence, thanks for the advice (albeit off
topic or not specific to SPF).

Post by Douglas Otis
You should put yourself into your customer's position. Proclamations
that with SPF, some domain can not be forged are specious.

Only when receiving MTA's don't implement SPF (or some other form of
domain anti-forgery technique). But those MTA's don't matter because
they won't bother to implement submission of forged emails to domain
based reputation lists (or would be irresponsible if they did).

Post by Douglas Otis
This of
course assumes closed-ended list, where the domain owner maintains
exclusive access to their servers.

Please explain, because I don't understand how you could possibly think
that (recall the include and redirect mechanisms).

It does require that if they relay through their ISP's mail server(s)
that their ISP publishes SPF, but how is that unreasonable? (No domain
authentication/authorization scheme can work 100% unless it has 100%
deployment, and cannot be held responsible for not working where it is
not deployed)

Post by Douglas Otis
Closed-ended lists are not
practical, nor do most domain owners manage their own MTAs with
exclusive access.

Ah, so now you are talking about cross customer forgery within the same
ISP. Well, either your ISP has to implement protocols to stop cross
customer forgery (or be proactive about dealing with it, but I don't buy
that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY.

But bottom line, the majority of forgery I doubt very much comes from
the same ISP as the domain owner. (That's my experience from my log
files, its someone else, often over seas, faking to be a user from my
domain to see if I foolishly whitelisted by own domain name).

Post by Douglas Otis
A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.

Unless of course, there are other people in the world how have not
implemented signature protection. Hmm, where have I heard before there
could be failures if a protocol doesn't have 100% deployment?

Post by Douglas Otis
Especially an email provider with dubious motives asking them to publish
SPF records. How on Earth can publishing an SPF record be in the
interest of the domain owner, after Microsoft proclaims server
authorization is the same as sender authentication?

If you see the folly of what Microsoft is trying to do to use SPF
records in ways not intended, GREAT! But that is not fault of SPF.

No matter what they did, the police could not stop my neighbour from
drinking and driving. Even when they impounded his car he then stole a
neighbours car. Does this mean that to solve the problem the police
should take cars away from everyone? No. They put the guy in jail
because HE was the one that did wrong.

And SPF should not be discouraged because MS is abusing it. MS should
be stopped from abusing it.

Post by Douglas Otis
A DomainKeys signature associated with the Sender header allows the
provider to accept accountability for their customers, without mandating
their customers change their email addresses or publish DNS records.

That's a great idea. Let me know when there is a free version of
DomainKeys. And it works with mailing lists. And it doesn't "violate
the anonymity" of email (not that I believe that email should be
anonymous, but that's one of the big whines I hear against correcting
forwarding).

Post by Douglas Otis
The provider could also offer to relay messages already signed by their
customers as well. Either of these scenarios would be fair.

But not free.

Post by Douglas Otis
With prior knowledge of the sender, perhaps in the case where an SPF
record is being used to establish a white-list, SPF could offer utility.
White-listing may be practical for typical bulk emailers, but not for
the majority of email domains. However, DomainKeys could supplant
reliance upon white-listing, without the overhead needed to maintain a
complex database that may create problematic overlaps.

I hear the words but I just don't see the weight of the arguments.

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
1. Introduction
[...]
Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm.

If you are talking of cross-user forgery, see SPF, section 10.4[1]. This
isn't something that can generally be solved by an authorization protocol
that works with a granularity of IP addresses.

You misunderstood the concern. An email provider likely handles
customers using many different mailbox-domains. Yes, there could be
cross-user forgery within a domain, but that was not the concern. There
could also be cross-domain forgery. The provider is expected to make
assurances that some range of domains is permitted specifically for
those provided access to the MTA. If the provider does not properly
authenticate the user (some still exchange passwords in the clear), or
does not evaluate the PRA, the domain owner is placed at risk by
publishing SPF records.

Uh, NO. SPF records should not be used to evaluate the PRA.

Post by Douglas Otis
The sender does not know what the recipient
uses to base their reputation assessments. Someone can get seriously
hurt heedlessly publishing SPF.

They do for receivers that correctly implement protocols (e.g. do not
use SPF records for PRA).

Someone could get seriously hurt if other protocols like TCP keepalives
are not properly implemented. That doesn't mean we shouldn't use TCP.
(repeat my drunk driving lecture here).

Post by Douglas Otis

Post by Julian Mehnle
If you are talking of something else, I don't know what it is.

Post by Douglas Otis
This harm could originate from a Zombied computer of such a customer.
The abuser may utilize SPF records to obfuscate where the message
originates to prolong their success, when seeing such messages are not
blocked by the sending server.

How could SPF records be used to "obfuscate" a message's origin? The last
time I looked, SPF didn't suppress the generation of "Received:" headers.

Anyone that utilizes a large provider and publishes an SPF record that,
in effect, proclaims such use, could enable an abuser to send from the
correct server, while still lying about who they are. SPF does not
prevent this problem.

Neither does domain keys, until of course the ISP/MSP upgrades the MTA
to prevent cross customer forgery. Once that is done, then EITHER
method works. Amazing, if everything is done then everything works, and
if only some things are done then only some things work. Fascinating.

Post by Douglas Otis
SPF requires assumed checks that may or may not
be performed. In fact, some of these checks may require a license. : (

Huh?

Post by Douglas Otis
The abuser may wish to play this game until they have scorched the
reputation of that domain, before usurping the identity of the next
available victim, all while thanking SPF for making their fun possible.

Ditto for any forgery method that can be circumvented. Including
domainkeys.

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender.

So what? Receivers are already doing the same with IP address white- and
black-lists. The world has not gone up in flames, though.

Quite typically, providers that employ a black-hole listing service,
will indicate the website of this service in the error message returned
in the session refusal. The person sending the message can opt to
immediately try a different provider to send their message. They may
also elect to complain to the black-hole listing service that indicated
the MTA they utilized is not properly administered.

Email that fails authorization/authentication do not get
checked/submitted to lists BECAUSE they have failed. Its only if the
email passes that you then check the domain against lists.

Post by Douglas Otis
Perhaps the server administration permitted access to the wrong person,
perhaps they accidentally enabled an open-proxy in their network,
perhaps they even allowed an open-relay. Whatever the problem, the
sender often knows where to go for restitution. As SPF is intended to
assist the filtering of messages

NO NO NO. It is to be used for MTA time rejection, not post acceptance
filtering. And SA uses it for post acceptance filtering, but SPF unto
itself will not cause the email to be rejected due to the incredibly low
score a FAIL is assigned.

Post by Douglas Otis
, filtering often employs a practice of
placing uncertain results into a junk folder. With SPF, there are many
shades of gray. : (

SPF is *not* PRA. Please stop the FUD.

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
How can the domain owner restore the use of their domain, after their
provider naively believes they can assume how a record will be
interpreted which has an undefined scope?

(I assume you aren't implying that the concepts of accountability and
reputation are fundamentally flawed.)

The assumption that a mailbox-domain can be authenticated without the
use of a signature is fundamentally flawed.

In your opinion, especially if your opinion is to sell domainkeys. The
only thing that could be considered "flawed" is that it disallows
anonymous forwarding without implementing some other forwarding method
(such as SRS, SES).

Post by Douglas Otis
Server authorization is far
too weak to base a presumption of having authenticated the sender.

Your argument does not hold even a drop of substance against the
HELO/EHLO name checking of SPF.

And it doesn't hold any credence if one (like I) don't believe in
anonymous forwarding.

Post by Douglas Otis
Server authorization in the manner of SPF also wrecks havoc on email's
architecture. There is no reason for this, when signatures require less
effort and create less collateral damage.

But signatures cost more money, requires MTA's everywhere to upgrade
(even those that don't WANT to participate), how is that not collateral
damage?

Post by Douglas Otis

Post by Julian Mehnle
There are no SPF records with an undefined scope. If, for v=spf1 records,
receivers choose to apply Sender-ID's inconsistent scope definition (PRA)
over that of SPF itself, is it SPF's fault?

So are you going to tell a 900 pound gorilla they are wrong? In the
end, the gorilla will have their way with you. ; )

The Open source community is a 1000 pound gorilla, once it aligns its
forces. Just because some big powerful idiot is king, does not mean the
kings way is right. Look through the history books, its what mutiny and
revolution are all about.

Post by Douglas Otis

Post by Julian Mehnle
Have you complained already to Microsoft and the IESG about Sender-ID
redefining v=spf1 records? If not, why do you keep bringing up this issue
here? To say that even though this inconsistency is not SPF's fault,
another draft can always be employed to destroy its usefulness?

Strange, I see the same author on both drafts? Who's fault is that?
Depreciate the use v=spf1 to be assured of avoiding this serious
conflict.

Cute. Why can't you just deploy DomainKeys, and let the best product
win. Why must you resolve to attack SPF? Are you that fearful that SPF
will succeed in the end that you feel a need to attack it to try to get
DomainKeys deployment to catch up?

Post by Douglas Otis

Post by Julian Mehnle
What if I submitted a draft to the IETF that conflicted with the DomainKeys
specification? Would that make DomainKeys useless (or harmful)?

What patent licensing restrictions would you impose?

Nothing valid. But who said the MS patent crap is valid? Its not even
issued yet, just applied for.

Post by Douglas Otis
Are you large
enough to make your claims a serious concern?

You don't need to be large to apply for a patent. But your missing the
point, the point was if someone applied for a patent that conflicted
with domainkeys, does that make domainkeys bad? I think not.

Post by Douglas Otis
Would you be asking
domain owners to fall into a trap, which over time as a ubiquitous
reputation program is applied, necessitates domain owners find providers
that license your scheme?

Um, that sounds like PRA, not SPF. Nothing like SPF at all in fact.
Interesting though, I wonder if it sounds like domainkeys?

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
10. Security Considerations
[...]
With this draft mandating more than one hundred DNS lookups,

The SPF specification does not "mandate more than one hundred" DNS lookups.
It mandates that a receiver must be prepared to perform at most 111 DNS
lookups. This does not mean that the usual case is anywhere near that.

Odd, but I see a required minimum as a mandate, and 111 is more than
100. If there are on average 5 queries created for every lookup, this
could mean 555 queries are required to resolve a server's authorization
for a single message.

Which would be cached. And the boundary case is likely only reached on
those trying to spam or do a DOS attack. But spammers don't win,
because their email is still delayed. And DOS attackers, well dealing
with DOS is a fact of life no matter WHAT protocols one implements.

Post by Douglas Otis

Post by Julian Mehnle

Post by Douglas Otis
this raises a concern regarding how the 20 second time limit is employed.
A local recursive DNS resolver may act as a UDP amplifier. Congestion
avoidance depends upon the application making the requests to wait, in
order to maintain stability.
[...]

This sounds like a valid concern.

Post by Douglas Otis
There should also be a warning about acceptance of duplicate records.

What do you mean by "duplicate records"?

DNS transactions are only protected by a 16 bit integer. Often routines
utilize the UDP port to multiplex results. The sequence of Domain Name
Server queries dictated by an SPF script may expose the port being used.
There is also a further risk that replicate queries, as possible with
Bind 8 for example, may again greatly increase the chances of guessing a
transaction. As this can be caused to happen repeatedly, success does
not need to be 100% for this to be a concern. The two-tier
recursive/non-recursive resolver was suggested as a defensive measure.
It just seems more informative than recommending DNS paranoia.

Agreed. IF one is using a DNS service with known vulnerabilities and IF
this and IF that THEN, well, you deserve to be vulnerable, don't you?


Terry

Post by Douglas Otis
-Doug

[Douglas Otis]

Post by Terry Fielder

Post by Douglas Otis
Abating abuse requires diligence. This diligence involves the
monitoring of servers. To protect the privacy of other customers, much
of an MTA server's operation remains hidden from the domain owner, who
is often just one of many typical customers. With SPF reliance on the
mailbox-domain, the server's administrator remains anonymous. Negligent
server operation will not directly impact the administrator, but instead
impacts the domain owner. A reputation system should hold accountable
those who are expected to maintain diligence in respect to security,
access, and operation. Holding an innocent, feckless party accountable
is simply an unfair practice. Dare I say even foolish?
By the time a domain owner is made aware that volumes of abuse has
emerged from some SPF authorized server, forging their mailbox-domain in
some unexpected header, the reputation of their domain may have become
unsuitable for email. The means to recoup their reputation in this
situation may not be practical.

Interesting so if SPF fails then SPF will fail.
I say this because the only way the domain owners reputation could have
1) they did not implement SPF to protect forgery of their domain

Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.
Publishing SPF provides these recipients with what they believe to be
confirmations, albeit flimsy, that your domain has actually sent the
message. Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Not offering this damning confirmation is the only sure means to avoid
being assessed in this manner. Rather than being incensed and reckless
by publishing SPF records, when weary of the spoofs and thinking SPF is
your salvation against this sea of troubles, consider your options
carefully. Know your exposures. SPF and abusers together pose very
serious threats.

Post by Terry Fielder
2) they did implement SPF, and it failed to protect the forgery of
their domain

You have again assumed the domain owner publishing SPF is in a position
to wage a defense against the forgery of their domain. SPF places this
duty onto the faceless email provider, who remains unscathed by their
acts of negligence. They may even claim proprietary checks are outside
their bailiwick, although it then offers an avenue for the forger to
impugn your reputation.

Post by Terry Fielder
SPF cannot be help responsible for #1

There are some providers that wish to force use of SPF, and there lies
the rub.

Post by Terry Fielder
#1 can only happen if SPF doesn't work, but if SPF doesn't work then all
this is moot.
Perhaps Doug, you are not talking about SPF, because "some unexpected
header" sounds an awful lot like you are referring to the la-la
dreamland that is PRA.
And SPF is *not* PRA. Please don't confused between PRA and SPF (no
matter what Meng has on the damn pobox website).

Millions of users soon will be running an application that will accrue
"user feedback" against the Purported Responsible Address algorithm
confirmed with the v=spf1 record, as widely promoted. You would be
rather foolish to ignore this. As an expert, you would be negligent
advising anyone to publish an v=spf1 record, and not insist they also
require PRA conflict protections. The first question a wary domain
owner would need to ask, "Do you enforce the PRA for all of your
customers?"

How is it that the same author appears on these two drafts, and yet this
conflict is not taken far more seriously? Offering advice to ignore
Sender-ID would be outright laughable, if it were not so serious. How
will you indemnify your customers from such negligence?

Post by Terry Fielder

Post by Douglas Otis
The domain owner may be innocent. They may also view their domain as
highly valuable. They may also be required to seek expensive legal
avenues to uncover the cause of their dilemma. With SPF building upon a
filtering paradigm, there may be no outward indication their messages
are being silently dropped or placed into junk folders either.

*sigh*
PRA may do silent dropping of email after acceptance..
SPF does MTA time rejection, so the sending MTA *must* know that the
email was undeliverable, which guarantees all real, legit connecting
MTA's get a clear rejection on the delivery status.
SA is the only major filtering that uses SPF after the fact, and even a
FAIL scores less then 1 (0.8 something by default) and SA recommends not
rejecting emails that score less than 5-10, then SPF unto itself cannot
be what caused the rejection after acceptance. Something else scored
the other 4-9 points that were need to cause the email to be rejected by SA!
So don't say SPF causes silent dropping of email, its simply not true.
Certainly not in the recommended use of SPF (MTA time rejection) and not
even in the common not recommended use of SPF (SA).

Yes, the PRA may make this much worse. What happens at the back-end,
when the PRA algorithm is a plug-in for Outlook? Now you have both
wonderfully weak algorithms being applied to your domain, all thanks to
SPF. You need to strongly advise against the use of v=spf1. It must
go! Don't publish v=spf1 records, and if you have published them, they
need to be removed, or at least replaced with a different version that
includes scope. When used for white-listing, the scope "ADMIN" could be
used. : )

Post by Terry Fielder

Post by Douglas Otis
It is not clear how the domain owner will recover reliable use of
their email domain after publishing SPF and then being exploited.

Domain owners can be exploited if they don't publish SPF, nothing
changes by publishing SPF except, if SPF really does work (as time has
shown once forwarders are fixed), SPF may prevent forgery that is the
exploitation that could have resulted in bad reputation.

What do you mean the domain owner's reputation can still be exploited?
What type of reputation system would base abuse assessments upon totally
unconfirmed identifiers? Hopefully, the only confirmed identifiers,
such as the MTA IP address, would then be used. It would be incredible
to have a domain assessed for not publishing an SPF record. I would
even commend them! Ask that their MTA properly confirm their HELO, that
they use S/MIME, DomainKeys, or any other strong method that identifies
the source of the message. SPF's weak and broken authorization scheme
will wreck havoc on email's delivery integrity.

Post by Terry Fielder

Post by Douglas Otis
This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse.

SPF is not ignoring concerns. The concerns you have stated are either
unfounded or apply to PRA, not SPF.

Both SPF and Sender-ID ignore the identity of the server administrator.
Both SPF and Sender-ID premise all assessment upon the domain-owner,
where the server administrator _never_ enters into consideration.

Post by Terry Fielder

Post by Douglas Otis
Nevertheless, abating abuse requires holding administrators
accountable and ensuring they stay on top of security, access,
and operational issues.

Are you suggesting every MTA operator review all inbound email for
forgery/spam/viruses and do something with the ones that are bad? Glad
I am not paying that bill.

I am suggesting the MTA administrator is the _only_ one that can respond
when there is a security problem, or inappropriate access is being
granted. The MTA administrator should monitor all outbound logs and
watch for excessive errors, or unusual levels of outbound email. They
also need to investigate abuse reports of their outbound email. None of
these duties can be expected of the domain owner. The domain owner has
scant few tools to even know when there is a problem, and even fewer for
correcting the situation. The MTA administrator has many tools and can
respond.

Post by Terry Fielder

Post by Douglas Otis
A reputation scheme MUST identify the source of abuse, and not the
"assumed" source of abuse.

SPF is not a reputation scheme.
SPF is a means to make reputation schemes accurate by preventing forgery.

SPF will not prevent forgery in most cases. In those cases where
forgery still occurs, disaster! SPF will change forgery from a nuisance
(remedied with bounce address tag validation), into a total meltdown of
the domain. You really need to avoid making specious claims about what
SPF may accomplish, without also considering what it may not accomplish.

Post by Terry Fielder

Post by Douglas Otis
A reputation scheme must hold those responsible, accountable. SPF
fails badly on both of these issues.

No, it doesn't. A reputation scheme allows domains to obtain
credibility (or not) based on what the domain has done in the past.

Do you really consider SPF is a means to authenticate the sender? What
assumptions are involved when arriving at that conclusion? This is why
SPF is so dangerous.

Post by Terry Fielder
SPF simply improves the ability for reputation schemes to be accurate by
preventing forgeries from affecting the reputation database.

Publishing SPF does not prevent forgeries. Many other protections must
be instantiated, where any missing element in this phalanx of required
protections permits forgery. SPF may even invite forgery. (Even
assuming it was practical to impose strict authorization to maintain
this claim.) In the typical case, the domain owner will likely be
blithely unaware of the essential elements needed to guard their
reputation. You have already declared that you will permit PRA forgery,
as in your view, this is not your concern.

SPF only offers server authorization. It would be foolish to call this
a forgery prevention scheme, as likely anyone with access to the same
server may be able to forge messages from a domain that authorizes the
server with SPF. These SPF records are public, so the abuser will not
be guessing who they can impersonate. : (

Post by Terry Fielder

Post by Douglas Otis
It is folly to think SPF will improve the integrity of email or
diminish the rate of abuse. A reputation scheme based upon SPF
authorization is certain to dramatically reduce email's integrity
for the majority of domain owners.

I would love to see your facts, or testing, to justify this statement.
Sounds like FUD.

Yes, I heard that speech several times. I would strongly advise you to
consider strong identifiers that can be defended. A domain owner would
be incredibly foolish to place their domain's reputation into the hands
of an email provider that scoffs at monitoring their server as being too
expensive. While SPF may permit providers a "What, me worry?" attitude,
it will be the consumer that will pay dearly.

Post by Terry Fielder

Post by Douglas Otis
By retaining a signature operation within their administrative control,
the domain owner would have far greater control over the fate of their
domain's reputation.

Smells like you want to sell domain owners (or their ISP/MSP) something.
A certificate perhaps? At least now I know your motivation for
attacking SPF.

Boy are you barking up the wrong tree. Turn around, I think someone
wants to see your license. : )

Post by Terry Fielder

Post by Douglas Otis
They could utilize the services of an email provider to relay email
from a dynamic location, without fear other abusive messages may be
confused as being from them.

Thank you for endorsing the use of SPF (because that is what SPF does,
only without the need for MUA upgrades to check signatures, and no need
for buying certificates).

You do not need to buy certificates for either DomainKeys or Identified
Internet Mail. I have no financial incentive for recommending either of
these proposals being consider ahead of SPF, other than a desire to see
email remain a viable means to openly exchange information. SPF does
not offer a fig leaf of protection.

You assume the email provider, who ensures access to the server, also
limits what is sent through the server. In the age of Zombied computers
everywhere, expect anyone with access will try anything. Your only
protection with SPF depends upon a poorly defined set of assurances that
must be made by a dubiously diligent provider. They may believe as you
do, that SPF is its own protection. After all, it would not be their
reputation damaged would it?

Post by Terry Fielder

Post by Douglas Otis
If their relay provider was lax at security or preventing abuse, the
domain owner can seek a different provider to rectify any resulting
problems.

Which is a good idea no matter what security protocols one implements
(or not) for their domain. Hence, thanks for the advice (albeit off
topic or not specific to SPF).

Somehow considering the alternative does seem on topic.

Post by Terry Fielder

Post by Douglas Otis
You should put yourself into your customer's position. Proclamations
that with SPF, some domain can not be forged are specious.

Only when receiving MTA's don't implement SPF (or some other form of
domain anti-forgery technique). But those MTA's don't matter because
they won't bother to implement submission of forged emails to domain
based reputation lists (or would be irresponsible if they did).

You have made the point as to why there are advantages avoiding the
publishing of SPF.

Post by Terry Fielder

Post by Douglas Otis
This of course assumes closed-ended list, where the domain owner
maintains exclusive access to their servers.

Please explain, because I don't understand how you could possibly think
that (recall the include and redirect mechanisms).
It does require that if they relay through their ISP's mail server(s)
that their ISP publishes SPF, but how is that unreasonable? (No domain
authentication/authorization scheme can work 100% unless it has 100%
deployment, and cannot be held responsible for not working where it is
not deployed)

It remains impossible to list servers of those recipients that forward
their email, for example. While I have seen it argued this problem is
now the fault of the recipient, it still results in the loss of
messages. The remedy is to offer a lowered level of server
authorization, at the expense of being forged at this level.

Post by Terry Fielder

Post by Douglas Otis
Closed-ended lists are not practical, nor do most domain owners
manage their own MTAs with exclusive access.

Ah, so now you are talking about cross customer forgery within the same
ISP. Well, either your ISP has to implement protocols to stop cross
customer forgery (or be proactive about dealing with it, but I don't buy
that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY.

But that mess will not impact your domain's reputation, unless you are
silly enough to offer SPF server authorization construed to be "sender
authentication."

Post by Terry Fielder
But bottom line, the majority of forgery I doubt very much comes from
the same ISP as the domain owner. (That's my experience from my log
files, its someone else, often over seas, faking to be a user from my
domain to see if I foolishly white-listed by own domain name).

It is futile to go after today's behavior without considering how that
behavior may change. Is it any wonder those promoting SPF don't want to
talk directly about these concerns, and instead treat their audience
like a bunch of patsies ready to believe anything? "Don't listen to
anyone raising concerns about SPF/Sender-ID, they're just trying to
spread FUD!" I have heard this speech several times already. I wonder
if I should take this as a personal attack. ; )

Post by Terry Fielder

Post by Douglas Otis
A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.

Unless of course, there are other people in the world how have not
implemented signature protection. Hmm, where have I heard before there
could be failures if a protocol doesn't have 100% deployment?

The signature can be ignored by the recipient without harm. It only
requires the sender to implement a signature scheme. They then do not
need any protective cooperation by every down stream server, as does
SPF/Sender-ID.

Post by Terry Fielder

Post by Douglas Otis
Especially an email provider with dubious motives asking them to publish
SPF records. How on Earth can publishing an SPF record be in the
interest of the domain owner, after Microsoft proclaims server
authorization is the same as sender authentication?

If you see the folly of what Microsoft is trying to do to use SPF
records in ways not intended, GREAT! But that is not fault of SPF.
No matter what they did, the police could not stop my neighbor from
drinking and driving. Even when they impounded his car he then stole a
neighbors car. Does this mean that to solve the problem the police
should take cars away from everyone? No. They put the guy in jail
because HE was the one that did wrong.
And SPF should not be discouraged because MS is abusing it. MS should
be stopped from abusing it.

How can you say Microsoft is wrong, and an SPF cabal is right? Again,
both drafts even share the same author. Why blame anyone for there not
being any definition on the scope of the SPF record. Depreciate v=spf1,
advise its removal, and get on with life.

Post by Terry Fielder

Post by Douglas Otis
A DomainKeys signature associated with the Sender header allows the
provider to accept accountability for their customers, without mandating
their customers change their email addresses or publish DNS records.

That's a great idea. Let me know when there is a free version of
DomainKeys. And it works with mailing lists. And it doesn't "violate
the anonymity" of email (not that I believe that email should be
anonymous, but that's one of the big whines I hear against correcting
forwarding).

Yes, there is a free version:
http://domainkeys.sourceforge.net/

Post by Terry Fielder

Post by Douglas Otis
The provider could also offer to relay messages already signed by their
customers as well. Either of these scenarios would be fair.

But not free.

Yes, free!

Post by Terry Fielder

Post by Douglas Otis
You misunderstood the concern. An email provider likely handles
customers using many different mailbox-domains. Yes, there could be
cross-user forgery within a domain, but that was not the concern. There
could also be cross-domain forgery. The provider is expected to make
assurances that some range of domains is permitted specifically for
those provided access to the MTA. If the provider does not properly
authenticate the user (some still exchange passwords in the clear), or
does not evaluate the PRA, the domain owner is placed at risk by
publishing SPF records.

Uh, NO. SPF records should not be used to evaluate the PRA.

Tell that to Microsoft. Let me know how that goes. : )

Post by Terry Fielder

Post by Douglas Otis
The sender does not know what the recipient uses to base their
reputation assessments. Someone can get seriously hurt heedlessly
publishing SPF.

They do for receivers that correctly implement protocols (e.g. do not
use SPF records for PRA).
Someone could get seriously hurt if other protocols like TCP keepalives
are not properly implemented. That doesn't mean we shouldn't use TCP.
(repeat my drunk driving lecture here).

What makes any SPF cabal the protocol authority? The SPF record did not
have a defined scope, where a scope was added when it became apparent
Sender-ID would attempt to use the same silly path registration scheme.
Microsoft claims their algorithm breaks less often and see their claim
equally valid, their view of scope should prevail.

Post by Terry Fielder

Post by Douglas Otis
Anyone that utilizes a large provider and publishes an SPF record that,
in effect, proclaims such use, could enable an abuser to send from the
correct server, while still lying about who they are. SPF does not
prevent this problem.

Neither does domain keys, until of course the ISP/MSP upgrades the MTA
to prevent cross customer forgery. Once that is done, then EITHER
method works. Amazing, if everything is done then everything works, and
if only some things are done then only some things work. Fascinating.

Sender-ID and SPF depend upon universal checks at each public MTA.
Signatures schemes only requires a sender implementation.

Post by Terry Fielder

Post by Douglas Otis
SPF requires assumed checks that may or may not be performed. In
fact, some of these checks may require a license. : (

Huh?

Yes, the PRA you wish would go away. Its back...

Post by Terry Fielder

Post by Douglas Otis
The abuser may wish to play this game until they have scorched the
reputation of that domain, before usurping the identity of the next
available victim, all while thanking SPF for making their fun possible.

Ditto for any forgery method that can be circumvented. Including
domainkeys.

While forging a message with SPF only requires access to any authorized
server (not even to the SMTP application), and the forgeries can
commence. That can not be said of DomainKeys.

Post by Terry Fielder

Post by Douglas Otis
Perhaps the server administration permitted access to the wrong person,
perhaps they accidentally enabled an open-proxy in their network,
perhaps they even allowed an open-relay. Whatever the problem, the
sender often knows where to go for restitution. As SPF is intended to
assist the filtering of messages

NO NO NO. It is to be used for MTA time rejection, not post acceptance
filtering. And SA uses it for post acceptance filtering, but SPF unto
itself will not cause the email to be rejected due to the incredibly low
score a FAIL is assigned.

You mean no one will ever receive a bad reputation based upon SPF server
authorization? The concern was what happens when they do.

Post by Terry Fielder

Post by Douglas Otis
, filtering often employs a practice of
placing uncertain results into a junk folder. With SPF, there are many
shades of gray. : (

SPF is *not* PRA. Please stop the FUD.

This problem is valid in both cases, and yes worse with PRA. Please
stop attempting to disavow Sender-IDs use of the v=spf1 record. I
suggest if anyone needs to be consulted, you should query the author of
both drafts.

Post by Terry Fielder

Post by Douglas Otis
The assumption that a mailbox-domain can be authenticated without the
use of a signature is fundamentally flawed.

In your opinion, especially if your opinion is to sell domainkeys. The
only thing that could be considered "flawed" is that it disallows
anonymous forwarding without implementing some other forwarding method
(such as SRS, SES).

Post by Douglas Otis
Server authorization is far
too weak to base a presumption of having authenticated the sender.

Your argument does not hold even a drop of substance against the
HELO/EHLO name checking of SPF.

You don't really expect anyone to care about the HELO do you? As far as
SPF is concerned, it is there when the message is a DSN. CSV offers
much lower overhead for this check anyway. I suspect it will come into
consideration once signatures are prevalent, and then the need will be
more readily perceived.

Post by Terry Fielder
And it doesn't hold any credence if one (like I) don't believe in
anonymous forwarding.

Thought so, but then you don't care about who is administering the
server.

Post by Terry Fielder

Post by Douglas Otis
Server authorization in the manner of SPF also wrecks havoc on email's
architecture. There is no reason for this, when signatures require less
effort and create less collateral damage.

But signatures cost more money, requires MTA's everywhere to upgrade
(even those that don't WANT to participate), how is that not collateral
damage?

These are myths at this point. The overhead required affects the CPU on
the mail server that has adequate margins to permit signatures without
upgrading equipment. Signatures offer less overhead. They even
represent less impact that SPF/Sender-ID.

Post by Terry Fielder

Post by Douglas Otis
So are you going to tell a 900 pound gorilla they are wrong? In the
end, the gorilla will have their way with you. ; )

The Open source community is a 1000 pound gorilla, once it aligns its
forces. Just because some big powerful idiot is king, does not mean the
kings way is right. Look through the history books, its what mutiny and
revolution are all about.

In some areas perhaps. I am 100% behind the open source effort. But be
serious, Microsoft controls too many desktops at this time to be
ignored. You do so, only at your peril.

Post by Terry Fielder

Post by Douglas Otis
Strange, I see the same author on both drafts? Who's fault is that?
Depreciate the use v=spf1 to be assured of avoiding this serious
conflict.

Cute. Why can't you just deploy DomainKeys, and let the best product
win. Why must you resolve to attack SPF? Are you that fearful that SPF
will succeed in the end that you feel a need to attack it to try to get
DomainKeys deployment to catch up?

I am pointing out what I see is still VERY wrong the SPF draft. I am
placing my comments here because I think SPF, when used in the manner
advocated, place the email community at risk. I would rather provide a
REAL means for people to publish a record that says I DO NOT ASSURE THE
PRA IDENTITY, without that becoming a liability. The way it is
currently defined, SPF is little more than a trap.

-Doug

[Alan DeKok]

Post by Douglas Otis
Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.
Publishing SPF provides these recipients with what they believe to be
confirmations, albeit flimsy, that your domain has actually sent the
message. Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Let's correct the false assumptions then, rather than throwing out
the proposal. Many people believe putting their computer on the net
is OK. When they get viruses, the answer isn't to ban the net, it's
to fix their beliefs.

Post by Douglas Otis
Not offering this damning confirmation is the only sure means to avoid
being assessed in this manner.

Not giving people tools is the best way to ensure they won't hurt
themselves.


I find it curious that there's opposition to a "harmful" proposal
like SPF, but the "harmful" practice of sending unauthenticated email
from anywhere on the net is called "roaming", and is deemed to be a
requirement of SMTP.

Weird.

All I know is that SPF has harmed me a lot less than "roaming" has.
The endless dribbles of email from clueless people to "postmaster" or
"webmaster" claiming that my domain has spammed them is tiring.

Alan DeKok.

[Douglas Otis]

Post by Alan DeKok

Post by Douglas Otis
Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.
Publishing SPF provides these recipients with what they believe to be
confirmations, albeit flimsy, that your domain has actually sent the
message. Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Let's correct the false assumptions then, rather than throwing out
the proposal. Many people believe putting their computer on the net
is OK. When they get viruses, the answer isn't to ban the net, it's
to fix their beliefs.

One major assumption needing corrected is the assumed scope implied by
an v=spf1 record. There are vendors able to exercise significant
influence with respect to their view of the scope implied by this
record. You have another group that feels they can declare a default
scope, in a manner they consider appropriate, albeit in conflict. Those
holding the Presumed is better than Purported need to recognize they
will not prevail.

A reasonable means to extricate the draft from this situation would be
to depreciate the use of v=spf1, advise its removals, and then document
a new spf2 scope. Even define a scope like "ADMIN", that indicates
there are _no_ assurances being made within mail stream regarding any
identifier. It would simply be used to indicate addresses being
administered by a particular domain. One could say "To ensure this
administrative domain does not accidentally get blocked, apply this to
your white-list."

Post by Alan DeKok

Post by Douglas Otis
Not offering this damning confirmation is the only sure means to avoid
being assessed in this manner.

Not giving people tools is the best way to ensure they won't hurt
themselves.
I find it curious that there's opposition to a "harmful" proposal
like SPF, but the "harmful" practice of sending unauthenticated email
from anywhere on the net is called "roaming", and is deemed to be a
requirement of SMTP.

I would not hand a child a circular saw, and then say don't worry about
pulling this trigger. SPF is handing a dangerous tool to the domain
owner without advising them of the serious risks they assume when
publishing. I find that outrageous.

I am not against authenticating the source of email. The use of SPF
does not authenticate the sender, it only provides "server
authorization" which is being construed as being "sender
authentication." There are valid alternatives that I would happily
endorse, such as DomainKeys, or even CSV. A mailbox-domain assertion
depends on too many assumptions to ever be safe as an identifier serving
as a basis for reputation.

Post by Alan DeKok
Weird.

As difficult as dealing with IP addresses are, they represent a stronger
identifier when logged against repeated events of abuse. They also more
directly impact the administrator. If there is an open-proxy or address
spoofing situation, perhaps assisted by way of a tunnel, they need to
squelch that problem. I too would like to see authentication move into
the name space. As I said, DomainKeys or CSV provides both safe and
fair names that can be authenticated. These identifiers can be
defended, and do not put the average consumer at risk of seeing their
domain's utility being destroyed by a negligent provider. Yes,
providers will be required to remain vigilant, unlike that suggested by
some SPF proponents.

Post by Alan DeKok
All I know is that SPF has harmed me a lot less than "roaming" has.
The endless dribbles of email from clueless people to "postmaster" or
"webmaster" claiming that my domain has spammed them is tiring.

I offered suggestions that a domain assertion could be added to the CSV
record that indicates all of a domain's emails are signed. This would
be a lightweight, single lookup extension that could allow any domain a
means to identify any message that purports to be from your domain, but
then must validate their signature. There are other issues related to
signatures where this would be a useful tool.

I describe this at:
http://www.kelkea.com/ietf/draft-otis-mass-reputation-01.html

-Doug

[Alan DeKok]

Post by Douglas Otis
One major assumption needing corrected is the assumed scope implied by
an v=spf1 record. There are vendors able to exercise significant
influence with respect to their view of the scope implied by this
record. You have another group that feels they can declare a default
scope, in a manner they consider appropriate, albeit in conflict.

This is a political issue, and not a flaw in the technical proposal.

Post by Douglas Otis
SPF is handing a dangerous tool to the domain owner without advising
them of the serious risks they assume when publishing. I find that
outrageous.

As you've said. The proponents have disagreed, and "never the twain
shall meet."

Post by Douglas Otis
I offered suggestions that a domain assertion could be added to the CSV
record that indicates all of a domain's emails are signed.

Which is a great idea.

Alan DeKok.

[Terry Fielder]

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Abating abuse requires diligence. This diligence involves the
monitoring of servers. To protect the privacy of other customers, much
of an MTA server's operation remains hidden from the domain owner, who
is often just one of many typical customers. With SPF reliance on the
mailbox-domain, the server's administrator remains anonymous. Negligent
server operation will not directly impact the administrator, but instead
impacts the domain owner. A reputation system should hold accountable
those who are expected to maintain diligence in respect to security,
access, and operation. Holding an innocent, feckless party accountable
is simply an unfair practice. Dare I say even foolish?
By the time a domain owner is made aware that volumes of abuse has
emerged from some SPF authorized server, forging their mailbox-domain in
some unexpected header, the reputation of their domain may have become
unsuitable for email. The means to recoup their reputation in this
situation may not be practical.

Interesting so if SPF fails then SPF will fail.
I say this because the only way the domain owners reputation could have
1) they did not implement SPF to protect forgery of their domain

Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.

Agreed, educate the masses. But good luck, because there are a lot of
computer users without the faintest clue of how things work. Hence why
phishing is so effective.

Post by Douglas Otis
Publishing SPF provides these recipients with what they believe to be
confirmations, albeit flimsy, that your domain has actually sent the
message.

I doubt most users have a clue what SPF means. Or domainkeys. Or PRA.

Post by Douglas Otis
Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Yes, along with the false assumption that domainkeys is the FUSSP.

Post by Douglas Otis
Not offering this damning confirmation is the only sure means to avoid
being assessed in this manner.

What confirmation??? The users don't see a little lock symbol which
they can misinterpret to see as secure. They simply don't see messages
that were rejected at the MTA.

Post by Douglas Otis
Rather than being incensed and reckless
by publishing SPF records, when weary of the spoofs and thinking SPF is
your salvation against this sea of troubles, consider your options
carefully. Know your exposures. SPF and abusers together pose very
serious threats.

SPF does not present the problem, abusers do. But abusers find
loopholes in all methods. If they didn't, then we would already have
the FUSSP.

Post by Douglas Otis

Post by Terry Fielder
2) they did implement SPF, and it failed to protect the forgery of
their domain

You have again assumed the domain owner publishing SPF is in a position
to wage a defense against the forgery of their domain.

Um, they waged the defense by publishing SPF knowing that means MTA's
that check SPF will reject the forgery of their domain. That *is*
waging the defense.

Post by Douglas Otis
SPF places this
duty onto the faceless email provider, who remains unscathed by their
acts of negligence.

"Act of negligence": Clearly you see SPF as a threat to your product.
Go promote DomainKeys by showing what it has to offer, rather then
trying to raise false and unsubstantiated claims against the competition.

Post by Douglas Otis
They may even claim proprietary checks are outside
their bailiwick, although it then offers an avenue for the forger to
impugn your reputation.

SPF is not proprietary. SPF is not PRA. PRA is proprietary. And where
does domainkeys lie? Free? Open source?

Post by Douglas Otis

Post by Terry Fielder
SPF cannot be help responsible for #1

There are some providers that wish to force use of SPF, and there lies
the rub.

When they do, its relevant for all I have seen, because said providers
are the domain DNS hoster and MSP for the domain, so they know where the
emails will come from. And if someone wants their SPF record to be
enhanced to include other MSP or IP's etc, I am sure they can.

If the domain providers pushing SPF were so bad, and were doing their
customers so bad, they wouldn't have any customers left: This is a free
society and the masses will take their money and business where they
want to.

Post by Douglas Otis

Post by Terry Fielder
#1 can only happen if SPF doesn't work, but if SPF doesn't work then all
this is moot.
Perhaps Doug, you are not talking about SPF, because "some unexpected
header" sounds an awful lot like you are referring to the la-la
dreamland that is PRA.
And SPF is *not* PRA. Please don't confused between PRA and SPF (no
matter what Meng has on the damn pobox website).

Millions of users soon will be running an application that will accrue
"user feedback" against the Purported Responsible Address algorithm
confirmed with the v=spf1 record, as widely promoted. You would be
rather foolish to ignore this.

I do not ignore it. I am very prepared to advise everyone to disable
the PRA when the latest version of exchange/whatever comes out. (Course
I also advise everyone to get rid of M$ Exchange)

Post by Douglas Otis
As an expert, you would be negligent
advising anyone to publish an v=spf1 record, and not insist they also
require PRA conflict protections. The first question a wary domain
owner would need to ask, "Do you enforce the PRA for all of your
customers?"

Don't need to, PRA should not be scooping SPFv1 records, they are proven
incompatible. PRA should use their own SPF2.0 records. Don't blame SPF
because PRA is doing something bad, blame PRA. And domain owners have a
defense against the PRA, publish the counter PRA record:
"spf2.0/pra ?all"
so PRA does not misinterpret the SPF as a PRA data.

Post by Douglas Otis
How is it that the same author appears on these two drafts, and yet this
conflict is not taken far more seriously?

I don't pretend to understand or care to understand who was underhanded
or bought or ulteriorly motivated that ended MARID up where it got. It
doesn't matter.

Post by Douglas Otis
Offering advice to ignore
Sender-ID would be outright laughable, if it were not so serious. How
will you indemnify your customers from such negligence?

I advise everyone of the need to ensure PRA is disabled, and if there
are concerns that others they communicate with do not disable PRA then
they should publish the SPF2.0 record:
spf2.0/pra ?all

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
The domain owner may be innocent. They may also view their domain as
highly valuable. They may also be required to seek expensive legal
avenues to uncover the cause of their dilemma. With SPF building upon a
filtering paradigm, there may be no outward indication their messages
are being silently dropped or placed into junk folders either.

*sigh*
PRA may do silent dropping of email after acceptance..
SPF does MTA time rejection, so the sending MTA *must* know that the
email was undeliverable, which guarantees all real, legit connecting
MTA's get a clear rejection on the delivery status.
SA is the only major filtering that uses SPF after the fact, and even a
FAIL scores less then 1 (0.8 something by default) and SA recommends not
rejecting emails that score less than 5-10, then SPF unto itself cannot
be what caused the rejection after acceptance. Something else scored
the other 4-9 points that were need to cause the email to be rejected by SA!
So don't say SPF causes silent dropping of email, its simply not true.
Certainly not in the recommended use of SPF (MTA time rejection) and not
even in the common not recommended use of SPF (SA).

Yes, the PRA may make this much worse. What happens at the back-end,
when the PRA algorithm is a plug-in for Outlook?

Umm, MTA checking algorithm's should *never* be applied at the MUA,
because its too late to do an MTA reject.

Don't blame SPF because PRA is bad.

You keep successfully arguing against PRA, thanks for being on the SPF
side. Too bad you cannot find any legitmate arguments against SPF.

Post by Douglas Otis
Now you have both
wonderfully weak algorithms being applied to your domain, all thanks to
SPF.

No, the wonderfully weak algorithm is because PRA is abusing SPFv1
records. Move on.

Post by Douglas Otis
You need to strongly advise against the use of v=spf1. It must
go! Don't publish v=spf1 records, and if you have published them, they
need to be removed, or at least replaced with a different version that
includes scope. When used for white-listing, the scope "ADMIN" could be
used. : )

No, publish SPF.

And if someone actually is stupid enough to deploy/enable PRA, then
publish the anti-pra record:
spf2.0/pra ?all

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
It is not clear how the domain owner will recover reliable use of
their email domain after publishing SPF and then being exploited.

Domain owners can be exploited if they don't publish SPF, nothing
changes by publishing SPF except, if SPF really does work (as time has
shown once forwarders are fixed), SPF may prevent forgery that is the
exploitation that could have resulted in bad reputation.

What do you mean the domain owner's reputation can still be exploited?

There are some listings that use current domain name accreditation, even
though there is nothing to stop the domain from being forged.

Post by Douglas Otis
What type of reputation system would base abuse assessments upon totally
unconfirmed identifiers?

None, I sure hope. But they do exist, even if it is admins fighting the
spam battle with local machine rules instead of subscribing to public
lists. And you have missed the point, SPF can make the lists better, it
cannot make them worse. So worse case is it doesn't make their accuracy
better then they already are.

Post by Douglas Otis
Hopefully, the only confirmed identifiers,
such as the MTA IP address, would then be used.

You seem to have missed the point of IP based reputation lists are not
sufficient, case and point: the IP repuation lists currently reduce
spam, but not even to a bearable amount.

Post by Douglas Otis
It would be incredible
to have a domain assessed for not publishing an SPF record. I would
even commend them! Ask that their MTA properly confirm their HELO, that
they use S/MIME, DomainKeys, or any other strong method that identifies
the source of the message. SPF's weak and broken authorization scheme
will wreck havoc on email's delivery integrity.

You are entitled to your (unsubstantiated) opinion.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse.

SPF is not ignoring concerns. The concerns you have stated are either
unfounded or apply to PRA, not SPF.

Both SPF and Sender-ID ignore the identity of the server administrator.

Nope, SPFv1 looks at the HELO, Sender-ID does not. Don't confuse SPF
with SenderID/PRA. (I need a macro here so I can easily repeat that to you)

Post by Douglas Otis
Both SPF and Sender-ID premise all assessment upon the domain-owner,
where the server administrator _never_ enters into consideration.

Wrong again, the server admin has to do at least *something* to have SPF
running on the server. And sometimes, as you argued above, its even the
server administrator that takes things into their own hands and
publishes on the domain owners behalf, knowing where the MX's are for
the domain and its ISP/ESP/hoster.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Nevertheless, abating abuse requires holding administrators
accountable and ensuring they stay on top of security, access,
and operational issues.

Are you suggesting every MTA operator review all inbound email for
forgery/spam/viruses and do something with the ones that are bad? Glad
I am not paying that bill.

I am suggesting the MTA administrator is the _only_ one that can respond
when there is a security problem, or inappropriate access is being
granted.

And if the resources were there for MTA administrators, we wouldn't have
a spam problem. But they don't, and so there exists a spam problem.

Post by Douglas Otis
The MTA administrator should monitor all outbound logs and
watch for excessive errors, or unusual levels of outbound email.

Perfect: Oops, a while ago a flood of spam went through our server,
sorry I did not notice it before a few million got through.

Post by Douglas Otis
They
also need to investigate abuse reports of their outbound email.

Obviously stated by someone who doesn't spend much time handling user
email complaints.

Post by Douglas Otis
None of
these duties can be expected of the domain owner.

For the small time vanity domain where the owner has no idea, doesn't
matter, recall your statement above about the ISP/MSP/hoster publishing
the SPF on behalf of the domain. Problem solved, even if the domain
owner cannot follow the instructions of the various tools to generate
SPF records.

Post by Douglas Otis
The domain owner has
scant few tools to even know when there is a problem, and even fewer for
correcting the situation. The MTA administrator has many tools and can
respond.

And does, with SPF, something that is tried, works except on forwarding
cases that should never exist anyway, and has measureable deployment.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
A reputation scheme MUST identify the source of abuse, and not the
"assumed" source of abuse.

SPF is not a reputation scheme.
SPF is a means to make reputation schemes accurate by preventing forgery.

SPF will not prevent forgery in most cases.

Wrong (the current SPF deployment testing shows it), please resist
making unsubstantiated claims.

Post by Douglas Otis
In those cases where
forgery still occurs, disaster!

In *what* cases can forgery still occur if SPF is properly implemented?

Post by Douglas Otis
SPF will change forgery from a nuisance
(remedied with bounce address tag validation), into a total meltdown of
the domain. You really need to avoid making specious claims about what
SPF may accomplish, without also considering what it may not accomplish.

You need to avoid making specious claims of problems that are not
actually caused by SPF but by PRA.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
A reputation scheme must hold those responsible, accountable. SPF
fails badly on both of these issues.

No, it doesn't. A reputation scheme allows domains to obtain
credibility (or not) based on what the domain has done in the past.

Do you really consider SPF is a means to authenticate the sender?

No, neither should you claim that SPF makes the claim. SPF says that
the MTA is authorized to send emails from said domain, so the email
*could* be legit.
SPF does not guarantee emails are good. It just guarantees they are not
forged.

Post by Douglas Otis
What
assumptions are involved when arriving at that conclusion? This is why
SPF is so dangerous.

No assumptions, using the same methodolgy that is applied to IP
reputation lists, can be provided for domain name reputation lists.
Only spammers have lots of IP's for their spamming activity, but fewer
domains with good reputation (and the reputation would turn bad after a
bit of abuse)

Post by Douglas Otis

Post by Terry Fielder
SPF simply improves the ability for reputation schemes to be accurate by
preventing forgeries from affecting the reputation database.

Publishing SPF does not prevent forgeries.

Yes it does. If you cannot trust that the MTA that you allow to send
your email cannot be trusted to not send forgeries from your domain,
then you have bigger problems with your ISP that not even signature
methodolgies can resolve.

Post by Douglas Otis
Many other protections must
be instantiated, where any missing element in this phalanx of required
protections permits forgery. SPF may even invite forgery.

Oh I cannot wait to hear why, please enlighten me with your wisdom.

Post by Douglas Otis
(Even
assuming it was practical to impose strict authorization to maintain
this claim.) In the typical case, the domain owner will likely be
blithely unaware of the essential elements needed to guard their
reputation. You have already declared that you will permit PRA forgery,
as in your view, this is not your concern.

Never said that. In fact I said I would fight the PRA, its worse then
useless.

Post by Douglas Otis
SPF only offers server authorization. It would be foolish to call this
a forgery prevention scheme, as likely anyone with access to the same

*likely* (If you cannot trust your MSP, you need to get a better one).

Post by Douglas Otis
server may be able to forge messages from a domain that authorizes the
server with SPF. These SPF records are public, so the abuser will not
be guessing who they can impersonate. : (

Your silly, without SPF you can still *easily* find out where the vast
of majority of domain names call home, by examining MX and other types
of SPf records.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
It is folly to think SPF will improve the integrity of email or
diminish the rate of abuse. A reputation scheme based upon SPF
authorization is certain to dramatically reduce email's integrity
for the majority of domain owners.

I would love to see your facts, or testing, to justify this statement.
Sounds like FUD.

Yes, I heard that speech several times. I would strongly advise you to
consider strong identifiers that can be defended. A domain owner would
be incredibly foolish to place their domain's reputation into the hands
of an email provider that scoffs at monitoring their server as being too
expensive. While SPF may permit providers a "What, me worry?" attitude,
it will be the consumer that will pay dearly.

I will certainly consider other methods of authentication, in fact I
would love to. I look forward to one being available, and deployable,
and free (as in beer).

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
By retaining a signature operation within their administrative control,
the domain owner would have far greater control over the fate of their
domain's reputation.

Smells like you want to sell domain owners (or their ISP/MSP) something.
A certificate perhaps? At least now I know your motivation for
attacking SPF.

Boy are you barking up the wrong tree. Turn around, I think someone
wants to see your license. : )

Could be, and they can see my license, because I publish SPF. :)

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
They could utilize the services of an email provider to relay email
from a dynamic location, without fear other abusive messages may be
confused as being from them.

Thank you for endorsing the use of SPF (because that is what SPF does,
only without the need for MUA upgrades to check signatures, and no need
for buying certificates).

You do not need to buy certificates for either DomainKeys or Identified
Internet Mail. I have no financial incentive for recommending either of
these proposals being consider ahead of SPF, other than a desire to see
email remain a viable means to openly exchange information. SPF does
not offer a fig leaf of protection.
You assume the email provider, who ensures access to the server, also
limits what is sent through the server. In the age of Zombied computers
everywhere, expect anyone with access will try anything. Your only
protection with SPF depends upon a poorly defined set of assurances that
must be made by a dubiously diligent provider. They may believe as you
do, that SPF is its own protection. After all, it would not be their
reputation damaged would it?

SPF is not the FUSSP. Never said it was. It just helps to build a
better framework so other mechanisms can work better. The fact that in
the short term it will quash spammers and viruses who have not adapted
is cool, but irrelevant.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
If their relay provider was lax at security or preventing abuse, the
domain owner can seek a different provider to rectify any resulting
problems.

Which is a good idea no matter what security protocols one implements
(or not) for their domain. Hence, thanks for the advice (albeit off
topic or not specific to SPF).

Somehow considering the alternative does seem on topic.

Post by Terry Fielder

Post by Douglas Otis
You should put yourself into your customer's position. Proclamations
that with SPF, some domain can not be forged are specious.

Only when receiving MTA's don't implement SPF (or some other form of
domain anti-forgery technique). But those MTA's don't matter because
they won't bother to implement submission of forged emails to domain
based reputation lists (or would be irresponsible if they did).

You have made the point as to why there are advantages avoiding the
publishing of SPF.

I don't see how.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
This of course assumes closed-ended list, where the domain owner
maintains exclusive access to their servers.

Please explain, because I don't understand how you could possibly think
that (recall the include and redirect mechanisms).
It does require that if they relay through their ISP's mail server(s)
that their ISP publishes SPF, but how is that unreasonable? (No domain
authentication/authorization scheme can work 100% unless it has 100%
deployment, and cannot be held responsible for not working where it is
not deployed)

It remains impossible to list servers of those recipients that forward
their email, for example.

Please peruse the archives for SRS and SES.

Post by Douglas Otis
While I have seen it argued this problem is
now the fault of the recipient, it still results in the loss of
messages.

If bad "anonymous" forwarding is still allowed. I don't think it
should. My servers don't do it, we re-inject so the end rejections come
back to the intermediate account.

Post by Douglas Otis
The remedy is to offer a lowered level of server
authorization, at the expense of being forged at this level.

That's a good point. But not even keys saves you if you cannot trust
the MTA that is authorized to send your email. *sigh*

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Closed-ended lists are not practical, nor do most domain owners
manage their own MTAs with exclusive access.

Ah, so now you are talking about cross customer forgery within the same
ISP. Well, either your ISP has to implement protocols to stop cross
customer forgery (or be proactive about dealing with it, but I don't buy
that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY.

But that mess will not impact your domain's reputation, unless you are
silly enough to offer SPF server authorization construed to be "sender
authentication."

Wrong again, I have already encountered small time mail admin who
blacklisted my domain name based on an infected computer that had few
addresses in the contact list, but one of my sales offices was. Just a
local blacklist, not any big damage, but sufficient headache nonetheless.

Post by Douglas Otis

Post by Terry Fielder
But bottom line, the majority of forgery I doubt very much comes from
the same ISP as the domain owner. (That's my experience from my log
files, its someone else, often over seas, faking to be a user from my
domain to see if I foolishly white-listed by own domain name).

It is futile to go after today's behavior without considering how that
behavior may change. Is it any wonder those promoting SPF don't want to
talk directly about these concerns, and instead treat their audience
like a bunch of patsies ready to believe anything? "Don't listen to
anyone raising concerns about SPF/Sender-ID, they're just trying to
spread FUD!" I have heard this speech several times already. I wonder
if I should take this as a personal attack. ; )

You can do what you like, its intended as a personal attack. But please
stop talking down SPF because PRA has serious flaws, because that is an
unfair attack against SPF.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.

Unless of course, there are other people in the world how have not
implemented signature protection. Hmm, where have I heard before there
could be failures if a protocol doesn't have 100% deployment?

The signature can be ignored by the recipient without harm. It only
requires the sender to implement a signature scheme. They then do not
need any protective cooperation by every down stream server, as does
SPF/Sender-ID.

Post by Terry Fielder

Post by Douglas Otis
Especially an email provider with dubious motives asking them to publish
SPF records. How on Earth can publishing an SPF record be in the
interest of the domain owner, after Microsoft proclaims server
authorization is the same as sender authentication?

If you see the folly of what Microsoft is trying to do to use SPF
records in ways not intended, GREAT! But that is not fault of SPF.
No matter what they did, the police could not stop my neighbor from
drinking and driving. Even when they impounded his car he then stole a
neighbors car. Does this mean that to solve the problem the police
should take cars away from everyone? No. They put the guy in jail
because HE was the one that did wrong.
And SPF should not be discouraged because MS is abusing it. MS should
be stopped from abusing it.

How can you say Microsoft is wrong, and an SPF cabal is right? Again,
both drafts even share the same author.

Irrelevant, the different drafts are *different* because just that: They
say completely different things.

Post by Douglas Otis
Why blame anyone for there not
being any definition on the scope of the SPF record. Depreciate v=spf1,
advise its removal, and get on with life.

Post by Terry Fielder

Post by Douglas Otis
A DomainKeys signature associated with the Sender header allows the
provider to accept accountability for their customers, without mandating
their customers change their email addresses or publish DNS records.

That's a great idea. Let me know when there is a free version of
DomainKeys. And it works with mailing lists. And it doesn't "violate
the anonymity" of email (not that I believe that email should be
anonymous, but that's one of the big whines I hear against correcting
forwarding).

http://domainkeys.sourceforge.net/

You have peaked my interest, I will look at it, domain keys had sounded
so much like a money grab before.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
The provider could also offer to relay messages already signed by their
customers as well. Either of these scenarios would be fair.

But not free.

Yes, free!

As above, I am going to look at it.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
You misunderstood the concern. An email provider likely handles
customers using many different mailbox-domains. Yes, there could be
cross-user forgery within a domain, but that was not the concern. There
could also be cross-domain forgery. The provider is expected to make
assurances that some range of domains is permitted specifically for
those provided access to the MTA. If the provider does not properly
authenticate the user (some still exchange passwords in the clear), or
does not evaluate the PRA, the domain owner is placed at risk by
publishing SPF records.

Uh, NO. SPF records should not be used to evaluate the PRA.

Tell that to Microsoft. Let me know how that goes. : )

MS has made many bad mistakes. They still live with many of them.
People still cope by disabling bad ideas like IIS web printing and crap
like that.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
The sender does not know what the recipient uses to base their
reputation assessments. Someone can get seriously hurt heedlessly
publishing SPF.

They do for receivers that correctly implement protocols (e.g. do not
use SPF records for PRA).
Someone could get seriously hurt if other protocols like TCP keepalives
are not properly implemented. That doesn't mean we shouldn't use TCP.
(repeat my drunk driving lecture here).

What makes any SPF cabal the protocol authority? The SPF record did not
have a defined scope, where a scope was added when it became apparent
Sender-ID would attempt to use the same silly path registration scheme.
Microsoft claims their algorithm breaks less often and see their claim
equally valid, their view of scope should prevail.

Unsubstantiated claims are irrelevant, which is why Marid ended to allow
for testing mode.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Anyone that utilizes a large provider and publishes an SPF record that,
in effect, proclaims such use, could enable an abuser to send from the
correct server, while still lying about who they are. SPF does not
prevent this problem.

Neither does domain keys, until of course the ISP/MSP upgrades the MTA
to prevent cross customer forgery. Once that is done, then EITHER
method works. Amazing, if everything is done then everything works, and
if only some things are done then only some things work. Fascinating.

Sender-ID and SPF depend upon universal checks at each public MTA.
Signatures schemes only requires a sender implementation.

But is useless without a receiver implementation. Sound familiar?

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
SPF requires assumed checks that may or may not be performed. In
fact, some of these checks may require a license. : (

Huh?

Yes, the PRA you wish would go away. Its back...

But not to stay, not with a license anyway, because many (like myself)
will not sign.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
The abuser may wish to play this game until they have scorched the
reputation of that domain, before usurping the identity of the next
available victim, all while thanking SPF for making their fun possible.

Ditto for any forgery method that can be circumvented. Including
domainkeys.

While forging a message with SPF only requires access to any authorized
server (not even to the SMTP application), and the forgeries can
commence. That can not be said of DomainKeys.

If you cannot trust your MTA, you cannot trust it, not for anything.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Perhaps the server administration permitted access to the wrong person,
perhaps they accidentally enabled an open-proxy in their network,
perhaps they even allowed an open-relay. Whatever the problem, the
sender often knows where to go for restitution. As SPF is intended to
assist the filtering of messages

NO NO NO. It is to be used for MTA time rejection, not post acceptance
filtering. And SA uses it for post acceptance filtering, but SPF unto
itself will not cause the email to be rejected due to the incredibly low
score a FAIL is assigned.

You mean no one will ever receive a bad reputation based upon SPF server
authorization? The concern was what happens when they do.

If the reputation lists find that SPF PASS is not sufficient to say its
from the domain, that does not preclude SPF still being useful to reject
the emails that definitely are *not* from the domain (and even better is
the fact that it is done at SMTP time).

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
, filtering often employs a practice of
placing uncertain results into a junk folder. With SPF, there are many
shades of gray. : (

SPF is *not* PRA. Please stop the FUD.

This problem is valid in both cases, and yes worse with PRA. Please
stop attempting to disavow Sender-IDs use of the v=spf1 record. I
suggest if anyone needs to be consulted, you should query the author of
both drafts.

Post by Terry Fielder

Post by Douglas Otis
The assumption that a mailbox-domain can be authenticated without the
use of a signature is fundamentally flawed.

In your opinion, especially if your opinion is to sell domainkeys. The
only thing that could be considered "flawed" is that it disallows
anonymous forwarding without implementing some other forwarding method
(such as SRS, SES).

Post by Douglas Otis
Server authorization is far
too weak to base a presumption of having authenticated the sender.

Your argument does not hold even a drop of substance against the
HELO/EHLO name checking of SPF.

You don't really expect anyone to care about the HELO do you?

I hope that someday the poorly configured MTA's will be forced to use a
valid HELO.

Post by Douglas Otis
As far as
SPF is concerned, it is there when the message is a DSN. CSV offers
much lower overhead for this check anyway.

Compared to the SPF worst case, yes. Compared to the average case, my
understanding is not.

Post by Douglas Otis
I suspect it will come into
consideration once signatures are prevalent, and then the need will be
more readily perceived.

When signatures actually go into production hopefully all this will be
irrelevant. But I doubt it. And we have SPF here, and now.

Post by Douglas Otis

Post by Terry Fielder
And it doesn't hold any credence if one (like I) don't believe in
anonymous forwarding.

Thought so, but then you don't care about who is administering the
server.

I don't follow your reasoning.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Server authorization in the manner of SPF also wrecks havoc on email's
architecture. There is no reason for this, when signatures require less
effort and create less collateral damage.

But signatures cost more money, requires MTA's everywhere to upgrade
(even those that don't WANT to participate), how is that not collateral
damage?

These are myths at this point. The overhead required affects the CPU on
the mail server that has adequate margins to permit signatures without
upgrading equipment. Signatures offer less overhead. They even
represent less impact that SPF/Sender-ID.

NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS
cache.

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
So are you going to tell a 900 pound gorilla they are wrong? In the
end, the gorilla will have their way with you. ; )

The Open source community is a 1000 pound gorilla, once it aligns its
forces. Just because some big powerful idiot is king, does not mean the
kings way is right. Look through the history books, its what mutiny and
revolution are all about.

In some areas perhaps. I am 100% behind the open source effort. But be
serious, Microsoft controls too many desktops at this time to be
ignored. You do so, only at your peril.

If you think spam is solved at the desktop. It is not. I don't see how
it ever can (or should) because you are still wasting resources allowing
the spam to get to the desktop when one could quash it at the MTA.

Have you noticed how many peolple have stopped using IE and have started
using firefox? Revolution...

Post by Douglas Otis

Post by Terry Fielder

Post by Douglas Otis
Strange, I see the same author on both drafts? Who's fault is that?
Depreciate the use v=spf1 to be assured of avoiding this serious
conflict.

Cute. Why can't you just deploy DomainKeys, and let the best product
win. Why must you resolve to attack SPF? Are you that fearful that SPF
will succeed in the end that you feel a need to attack it to try to get
DomainKeys deployment to catch up?

I am pointing out what I see is still VERY wrong the SPF draft. I am
placing my comments here because I think SPF, when used in the manner
advocated, place the email community at risk. I would rather provide a
REAL means for people to publish a record that says I DO NOT ASSURE THE
PRA IDENTITY, without that becoming a liability. The way it is
currently defined, SPF is little more than a trap.

Not when you can negate the PRA concern with: spf2.0/pra ?all

Post by Douglas Otis
-Doug

[Douglas Otis]

Post by Terry Fielder

Post by Douglas Otis
Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.

Agreed, educate the masses. But good luck, because there are a lot of
computer users without the faintest clue of how things work. Hence why
phishing is so effective.

It does not need to be a pad-lock icon to create an impression the
sender has been assured. Calling "server authorization" "sender
authentication" does little to educate users. If anything, this
misrepresentation increases the number of victims, and allows phishers a
new means to gain the confidence of their victim. A "happy face" is
equally misleading, when this is understood to be that the sender has
been authenticated. The mailbox-domain can not be authenticated without
a signature.

Post by Terry Fielder

Post by Douglas Otis
Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Yes, along with the false assumption that domainkeys is the FUSSP.

Sender-ID/SPF is being touted as a means to accrue reputations based
upon the SPF record. This is not an innocuous tool. These weak server
authorizations are easily exploited by an abuser. Abuse prevention
depends upon the provider's access control and added impositions of
mailbox-domain restrictions. By the domain owner publishing the SPF
authorization, they enable accrual of a likely unfair reputation.

Instead of alerting domain owners as to what is needed for the
protection of their domain's reputation, promoters are advising domain
owners to consider any concerns over publishing of SPF records to be
irrelevant FUD. This is usually accompanied with rhetoric that
describes some corner case, and its dismissal. In addition to message
loss, I have yet to hear that publishing may cause your domain's
reputation to be irreparably damaged, should the provider fail to
enforce the new needed restrictions. This failure could happen with the
provider enables an open-proxy or open-relay. It may also occur when
the provider permits access to their server's other applications that
could be subverted into sending mail.

No email abuse will be abated without being used in conjunction with a
reputation system. There are not the same exposures created by
DomainKeys, as with SPF. DomainKeys provides for authentication,
whereas Sender-ID does not.

Post by Terry Fielder
Um, they waged the defense by publishing SPF knowing that means MTA's
that check SPF will reject the forgery of their domain. That *is*
waging the defense.

Under particular, impractical circumstances, SPF may allow some emails
to be refused on the basis that the server is not authorized. SPF will
not prevent the domain being forged, when access is granted to a shared
server. When the authorization is open-ended, SPF will not prevent
forgery. Again, anti-forgery claims are specious.

Post by Terry Fielder
Go promote DomainKeys by showing what it has to offer, rather then
trying to raise false and unsubstantiated claims against the competition.

Rather than side-stepping this issue, be specific about the claims.

Post by Terry Fielder

Post by Douglas Otis
They may even claim proprietary checks are outside
their bailiwick, although it then offers an avenue for the forger to
impugn your reputation.

SPF is not proprietary. SPF is not PRA. PRA is proprietary.

SPF records _will_ be used for the PRA algorithm, that may result in
domain's reputation being damaged when ignored and not assured by the
provider.

Post by Terry Fielder

Post by Douglas Otis
There are some providers that wish to force use of SPF, and there lies
the rub.

...

Post by Terry Fielder
If the domain providers pushing SPF were so bad, and were doing their
customers so bad, they wouldn't have any customers left: This is a free
society and the masses will take their money and business where they
want to.

With a high percentage using a common desktop OS, the influence this
creates requires greater consideration. I do not believe the a
community will be able to prevent interpretation of a record's scope
from being applied to the PRA, without making the scope for the record
explicitly expressed. After all, their draft shares the same author,
and there was a very short period of time when this was considered
permissible within MARID group.

Post by Terry Fielder

Post by Douglas Otis
Millions of users soon will be running an application that will accrue
"user feedback" against the Purported Responsible Address algorithm
confirmed with the v=spf1 record, as widely promoted. You would be
rather foolish to ignore this.

I do not ignore it. I am very prepared to advise everyone to disable
the PRA when the latest version of exchange/whatever comes out. (Course
I also advise everyone to get rid of M$ Exchange)

Again, don't expect to prevail.

Post by Terry Fielder

Post by Douglas Otis
As an expert, you would be negligent advising anyone to publish an
v=spf1 record, and not insist they also require PRA conflict
protections. The first question a wary domain owner would need to
ask, "Do you enforce the PRA for all of your customers?"

Don't need to, PRA should not be scooping SPFv1 records, they are proven
incompatible. PRA should use their own SPF2.0 records. Don't blame SPF
because PRA is doing something bad, blame PRA. And domain owners have a
"spf2.0/pra ?all"
so PRA does not misinterpret the SPF as a PRA data.

At the same time, domain owners are warned that ?all will eventually
become a basis for refusal. This "neutral" authorization, although
weak, may still be viewed as confirmation sufficient for expressing some
level of "authentication." There have also been warnings regarding the
potential damage weak authorizations may create. Forcing the publishing
of a PRA record is a strange method to indicate that you refuse to allow
the PRA to be evaluated. I would say this suggests just the opposite.

Post by Terry Fielder

Post by Douglas Otis
Offering advice to ignore Sender-ID would be outright laughable, if
it were not so serious. How will you indemnify your customers from
such negligence?

I advise everyone of the need to ensure PRA is disabled, and if there
are concerns that others they communicate with do not disable PRA then
spf2.0/pra ?all

Your customers have NO control over what some recipient may do. This
record does not assure their reputation remains protected. In fact,
there have been statements made to the opposite. There have also been
warnings that in the future this record will be refused.

Post by Terry Fielder

Post by Douglas Otis
Yes, the PRA may make this much worse. What happens at the back-end,
when the PRA algorithm is a plug-in for Outlook?

Umm, MTA checking algorithm's should *never* be applied at the MUA,
because its too late to do an MTA reject.
Don't blame SPF because PRA is bad.
You keep successfully arguing against PRA, thanks for being on the SPF
side. Too bad you cannot find any legitmate arguments against SPF.

Both SPF and Sender-ID proponents proposed the use of reputations based
upon server authorization. This raises a legitimate concern. Both SPF
and Sender-ID fail to hold the server administrator accountable for the
operation of the server, and instead unfairly place the feckless domain
owner's reputation at risk. Both SPF and Sender-ID depend upon added
restrictions imposed by the email provider, but should the providers
fail to perform these new added duties, in addition to their normal
duties, the domain owner's reputation is unfairly put at risk.

Both SPF and Sender-ID wreck havoc with email's architectural paradigms
that will cause the loss of valid emails, and lower the integrity of
email delivery. The proponents of Sender-ID claim less loss of
messages. The unfair reputation system created by either SPF or
Sender-ID will lower the integrity of email delivery as well.

Post by Terry Fielder

Post by Douglas Otis
Now you have both wonderfully weak algorithms being applied to your
domain, all thanks to SPF.

No, the wonderfully weak algorithm is because PRA is abusing SPFv1
records. Move on.

You can not prevail on an assumed record scope. Both Sender-ID and SPF
attempt to transform "server authorization" into "sender
authentication." If I were to authorize an email provider, would that
mean any message using my email domain from that provider be from me?

Post by Terry Fielder

Post by Douglas Otis
You need to strongly advise against the use of v=spf1. It must
go! Don't publish v=spf1 records, and if you have published them, they
need to be removed, or at least replaced with a different version that
includes scope. When used for white-listing, the scope "ADMIN" could be
used. : )

No, publish SPF.
And if someone actually is stupid enough to deploy/enable PRA, then
spf2.0/pra ?all

One would need to be rather gullible to consider this record is
providing any protection, especially for the long term. I would
describe this as a trap. With the very few warning made, don't you find
these to foretell intended strategies?

Post by Terry Fielder

Post by Douglas Otis

Post by Terry Fielder
Domain owners can be exploited if they don't publish SPF, nothing
changes by publishing SPF except, if SPF really does work (as time has
shown once forwarders are fixed), SPF may prevent forgery that is the
exploitation that could have resulted in bad reputation.

What do you mean the domain owner's reputation can still be exploited?

There are some listings that use current domain name accreditation, even
though there is nothing to stop the domain from being forged.

Accreditations often depend upon the IP address in the same manner as an
SPF record. This type of service is often used by bulk emails. These
providers likely enjoy exclusive access to the "authorized" servers.
However, exclusive access should not be a requirement for a typical
domain owner. It is often not the case. Even so, not publishing SPF
still affords this domain owner greater protection.

Post by Terry Fielder

Post by Douglas Otis
What type of reputation system would base abuse assessments upon totally
unconfirmed identifiers?

None, I sure hope. But they do exist, even if it is admins fighting the
spam battle with local machine rules instead of subscribing to public
lists. And you have missed the point, SPF can make the lists better, it
cannot make them worse. So worse case is it doesn't make their accuracy
better then they already are.

I do not agree. SPF hopes to make this practice endemic. Filtering is
attempting to treat a disease, while also lowering email's integrity.
Only with strong and definitive results, can email's integrity be
retained. Signatures are strong and do not alter email's architectural
paradigms. SPF is weak, and breaks email.

Post by Terry Fielder

Post by Douglas Otis
Hopefully, the only confirmed identifiers,
such as the MTA IP address, would then be used.

You seem to have missed the point of IP based reputation lists are not
sufficient, case and point: the IP repuation lists currently reduce
spam, but not even to a bearable amount.

The degree to which IP address lists are ineffective is dependent upon
the diligence afford by large providers to administer their services.
SPF will only likely cause these providers to be less diligent and
assume there can be reliance upon SPF server authorization. This will
result in there being a total mess, and a disaster for many otherwise
responsible domain owners who will loss their ability to utilize their
domains.

Post by Terry Fielder

Post by Douglas Otis
Both SPF and Sender-ID premise all assessment upon the domain-owner,
where the server administrator _never_ enters into consideration.

Wrong again, the server admin has to do at least *something* to have SPF
running on the server. And sometimes, as you argued above, its even the
server administrator that takes things into their own hands and
publishes on the domain owners behalf, knowing where the MX's are for
the domain and its ISP/ESP/hoster.

The domain owner must publish the SPF record. The domain owner is not
the email provider running the authorized servers.

Post by Terry Fielder

Post by Douglas Otis
I am suggesting the MTA administrator is the _only_ one that can respond
when there is a security problem, or inappropriate access is being
granted.

And if the resources were there for MTA administrators, we wouldn't have
a spam problem. But they don't, and so there exists a spam problem.

Funny, SPF expects these same providers to do even more, but I suspect
they will do even less.

Post by Terry Fielder

Post by Douglas Otis
The MTA administrator should monitor all outbound logs and
watch for excessive errors, or unusual levels of outbound email.

Perfect: Oops, a while ago a flood of spam went through our server,
sorry I did not notice it before a few million got through.

Your reputation should suffer, and not your customer's.

Post by Terry Fielder

Post by Douglas Otis
They also need to investigate abuse reports of their outbound email.

Obviously stated by someone who doesn't spend much time handling user
email complaints.

I did say should. : )

Even so, the lax provider will not harm their reputation under the SPF
reputation strategy, it will be their customers. How self serving.

Post by Terry Fielder

Post by Douglas Otis
None of these duties can be expected of the domain owner.

For the small time vanity domain where the owner has no idea, doesn't
matter, recall your statement above about the ISP/MSP/hoster publishing
the SPF on behalf of the domain. Problem solved, even if the domain
owner cannot follow the instructions of the various tools to generate
SPF records.

I can see you don't care the least what happens when reputation is applied.

Post by Terry Fielder

Post by Douglas Otis
The domain owner has
scant few tools to even know when there is a problem, and even fewer for
correcting the situation. The MTA administrator has many tools and can
respond.

And does, with SPF, something that is tried, works except on forwarding
cases that should never exist anyway, and has measureable deployment.

Blame decades of use of a valuable feature?

Post by Terry Fielder

Post by Douglas Otis
SPF will not prevent forgery in most cases.

Wrong (the current SPF deployment testing shows it), please resist
making unsubstantiated claims.

Post by Douglas Otis
In those cases where
forgery still occurs, disaster!

In *what* cases can forgery still occur if SPF is properly implemented?

Exactly!

Post by Terry Fielder

Post by Douglas Otis
SPF will change forgery from a nuisance
(remedied with bounce address tag validation), into a total meltdown of
the domain. You really need to avoid making specious claims about what
SPF may accomplish, without also considering what it may not accomplish.

You need to avoid making specious claims of problems that are not
actually caused by SPF but by PRA.

It will plague both.

Post by Terry Fielder

Post by Douglas Otis
Do you really consider SPF is a means to authenticate the sender?

No, neither should you claim that SPF makes the claim. SPF says that
the MTA is authorized to send emails from said domain, so the email
*could* be legit.
SPF does not guarantee emails are good. It just guarantees they are not
forged.

Wrong again.

Post by Terry Fielder

Post by Douglas Otis
What
assumptions are involved when arriving at that conclusion? This is why
SPF is so dangerous.

No assumptions, using the same methodolgy that is applied to IP
reputation lists, can be provided for domain name reputation lists.
Only spammers have lots of IP's for their spamming activity, but fewer
domains with good reputation (and the reputation would turn bad after a
bit of abuse)

The use of a name offers greater freedom for imposing reputation. There
are potentially more names than addresses.

Post by Terry Fielder

Post by Douglas Otis
Publishing SPF does not prevent forgeries.

Yes it does. If you cannot trust that the MTA that you allow to send
your email cannot be trusted to not send forgeries from your domain,
then you have bigger problems with your ISP that not even signature
methodolgies can resolve.

How can a domain owner know how well their ISP defends their domain's
reputation. What recourse do they have when they don't?

Post by Terry Fielder

Post by Douglas Otis
Many other protections must
be instantiated, where any missing element in this phalanx of required
protections permits forgery. SPF may even invite forgery.

Oh I cannot wait to hear why, please enlighten me with your wisdom.

Access.

Post by Terry Fielder

Post by Douglas Otis
(Even
assuming it was practical to impose strict authorization to maintain
this claim.) In the typical case, the domain owner will likely be
blithely unaware of the essential elements needed to guard their
reputation. You have already declared that you will permit PRA forgery,
as in your view, this is not your concern.

Never said that. In fact I said I would fight the PRA, its worse then
useless.

By ignoring the PRA, you and your customer becomes its victim.

Post by Terry Fielder

Post by Douglas Otis
SPF only offers server authorization. It would be foolish to call this
a forgery prevention scheme, as likely anyone with access to the same

*likely* (If you cannot trust your MSP, you need to get a better one).

That will not remove the damage.

Post by Terry Fielder

Post by Douglas Otis
server may be able to forge messages from a domain that authorizes the
server with SPF. These SPF records are public, so the abuser will not
be guessing who they can impersonate. : (

Your silly, without SPF you can still *easily* find out where the vast
of majority of domain names call home, by examining MX and other types
of SPf records.

Usurping SPF based reputations requires SPF records.

Post by Terry Fielder

Post by Douglas Otis

Post by Terry Fielder
I would love to see your facts, or testing, to justify this statement.
Sounds like FUD.

Yes, I heard that speech several times. I would strongly advise you to
consider strong identifiers that can be defended. A domain owner would
be incredibly foolish to place their domain's reputation into the hands
of an email provider that scoffs at monitoring their server as being too
expensive. While SPF may permit providers a "What, me worry?" attitude,
it will be the consumer that will pay dearly.

I will certainly consider other methods of authentication, in fact I
would love to. I look forward to one being available, and deployable,
and free (as in beer).

What problem do you see with DomainKeys for example?

Post by Terry Fielder

Post by Douglas Otis
You do not need to buy certificates for either DomainKeys or Identified
Internet Mail. I have no financial incentive for recommending either of
these proposals being consider ahead of SPF, other than a desire to see
email remain a viable means to openly exchange information. SPF does
not offer a fig leaf of protection.
You assume the email provider, who ensures access to the server, also
limits what is sent through the server. In the age of Zombied computers
everywhere, expect anyone with access will try anything. Your only
protection with SPF depends upon a poorly defined set of assurances that
must be made by a dubiously diligent provider. They may believe as you
do, that SPF is its own protection. After all, it would not be their
reputation damaged would it?

SPF is not the FUSSP. Never said it was. It just helps to build a
better framework so other mechanisms can work better. The fact that in
the short term it will quash spammers and viruses who have not adapted
is cool, but irrelevant.

SPF does NOT build a better framework. Just the opposite. It leads to
very bad results when authorization is consider to be the same as
authentication.

Post by Terry Fielder

Post by Douglas Otis
It remains impossible to list servers of those recipients that forward
their email, for example.

Please peruse the archives for SRS and SES.

Post by Douglas Otis
While I have seen it argued this problem is
now the fault of the recipient, it still results in the loss of
messages.

If bad "anonymous" forwarding is still allowed. I don't think it
should. My servers don't do it, we re-inject so the end rejections come
back to the intermediate account.

All of this looks like a real mess.

Post by Terry Fielder

Post by Douglas Otis
The remedy is to offer a lowered level of server
authorization, at the expense of being forged at this level.

That's a good point. But not even keys saves you if you cannot trust
the MTA that is authorized to send your email. *sigh*

The domain owner only needs to trust the signing process and not each
and every MTA involved in the delivery of their message.

Post by Terry Fielder

Post by Douglas Otis
How can you say Microsoft is wrong, and an SPF cabal is right? Again,
both drafts even share the same author.

Irrelevant, the different drafts are *different* because just that: They
say completely different things.

They both use the same record for different mailbox-domains and then
presume the sender on that basis. Really bad.

Post by Terry Fielder

Post by Douglas Otis
Sender-ID and SPF depend upon universal checks at each public MTA.
Signatures schemes only requires a sender implementation.

But is useless without a receiver implementation. Sound familiar?

Signatures only requires that the end-points implement the protocol to
be beneficial. SPF or Sender-ID requires each and every MTA implement
the protocol, or their reputation can become seriously damaged.

Post by Terry Fielder

Post by Douglas Otis
Yes, the PRA you wish would go away. Its back...

But not to stay, not with a license anyway, because many (like myself)
will not sign.

You are setting yourself up for being forced into using the PRA it would
seem.

Post by Terry Fielder

Post by Douglas Otis
While forging a message with SPF only requires access to any authorized
server (not even to the SMTP application), and the forgeries can
commence. That can not be said of DomainKeys.

If you cannot trust your MTA, you cannot trust it, not for anything.

Not true. It can still be trusted with a signature based system. Just
like the WiFi at the coffeeshop can only be trusted with end-to-end
encryption.

Post by Terry Fielder

Post by Douglas Otis
You mean no one will ever receive a bad reputation based upon SPF server
authorization? The concern was what happens when they do.

If the reputation lists find that SPF PASS is not sufficient to say its
from the domain, that does not preclude SPF still being useful to reject
the emails that definitely are *not* from the domain (and even better is
the fact that it is done at SMTP time).

Perhaps this small feature would be useful, but I doubt that will ever
be practical when considering the impact this has on forwarded email.
The danger happens when too many consider this useful as a basis of
sender authentication, and then use it to apply reputations.

Post by Terry Fielder
When signatures actually go into production hopefully all this will be
irrelevant. But I doubt it. And we have SPF here, and now.

Neither signatures, or Sender-ID will protect network resources. The
requirement of over one hundred lookups by SPF also can not be defended.
CSV however does offer a means to thwart attacks.

Post by Terry Fielder

Post by Douglas Otis
These are myths at this point. The overhead required affects the CPU on
the mail server that has adequate margins to permit signatures without
upgrading equipment. Signatures offer less overhead. They even
represent less impact that SPF/Sender-ID.

NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS
cache.

There is still the effort needed to obtain the many SPF records for each
and every message.

Post by Terry Fielder

Post by Douglas Otis
I am pointing out what I see is still VERY wrong the SPF draft. I am
placing my comments here because I think SPF, when used in the manner
advocated, place the email community at risk. I would rather provide a
REAL means for people to publish a record that says I DO NOT ASSURE THE
PRA IDENTITY, without that becoming a liability. The way it is
currently defined, SPF is little more than a trap.

Not when you can negate the PRA concern with: spf2.0/pra ?all

This is wishful thinking.


-Doug

[Graham Murray]

Post by Douglas Otis
You can not prevail on an assumed record scope. Both Sender-ID and SPF
attempt to transform "server authorization" into "sender
authentication." If I were to authorize an email provider, would that
mean any message using my email domain from that provider be from me?

I cannot comment on Sender-ID, but as I understand it (as the one who
publishes SPF records for the domain) SPF does not attempt to do this. An SPF
pass does *NOT* indicate that the mail is genuinely from the domain (though in
the cases of the domains I control it probably does as I also control the mail
servers), but an SPF fail indicates that the mail is definitely NOT genuinely
from the domain. So an SPF pass should not be counted as sender
authentication, even domain keys does not do this (it only authenticates the
domain and that the mail has not been 'tampered with')- if you want to
authenticate the sender you will have to use an MUA cryptographic system like
S/MIME or PGP/MIME etc.

[Douglas Otis]

Post by Graham Murray

Post by Douglas Otis
You can not prevail on an assumed record scope. Both Sender-ID and SPF
attempt to transform "server authorization" into "sender
authentication." If I were to authorize an email provider, would that
mean any message using my email domain from that provider be from me?

I cannot comment on Sender-ID, but as I understand it (as the one who
publishes SPF records for the domain) SPF does not attempt to do this. An SPF
pass does *NOT* indicate that the mail is genuinely from the domain (though in
the cases of the domains I control it probably does as I also control the mail
servers), but an SPF fail indicates that the mail is definitely NOT genuinely
from the domain. So an SPF pass should not be counted as sender
authentication, even domain keys does not do this (it only authenticates the
domain and that the mail has not been 'tampered with')- if you want to
authenticate the sender you will have to use an MUA cryptographic system like
S/MIME or PGP/MIME etc.

Not granting an RFC for Sender-ID will not prevent the promised use of
the PRA algorithm with version 1 SPF records. While you may not desire
such PRA treatment of your email, publishing _any_ SPF record, as
currently defined, enables use of the PRA algorithm. The way this use
can be prevented would be to depreciate version 1 SPF records, and to
define scopes with version 2 SPF records that clearly indicate which
identities are 'assured' within messages. Also add a scope of 'ADMIN'
where no identifiers are assured, to allow the SPF records be used for
purely white-listing purposes.

Being practical, remove the HELO scope from the SPF records. CSV can
assure a single lookup for this purpose, and CSV offers a mechanism to
declare domain-wide email policies, to increase email requirements of
such things as CSV itself, or email signing, etc. In this way, CSV
offers DoS protections for any subsequent email extension.

Many have commented that a "benefit" of SPF is it forces abusers to use
their 'real' domain name, so they can be identified and stopped. This
comment illustrates an expectation that SPF provides "sender
authentication" where an abuser can not forge the mailbox-domain. While
possible, with add restrictions imposed by the email provider, the
domain owner remains completely at the mercy of an email provider's
diligence at _every_ MTA involved in the transport of the message, and
not just those MTAs that have been directly authorized by the SPF
record. A mistake on the part of an email provider, such as
misconfiguration of a firewall, and the domain owner's reputation
suffers.

A domain owner will have few resources to know the cause of their
reputation woes, and will need to wait for the TTL of their SPF records
to expire, before ill-advised publishing can be retracted, assuming they
even know which servers are at fault.

SPF offers many shades of gray, such as Pass, Neutral, SoftFail, or
TempError. An abuser could have their forged messages accepted at any
of these levels. Reputation and "assumed sender authentication" will
combine to sort out these results. It is very likely an abuser, finding
they _can_ forge a domain with a published SPF record, will cause the
messages from that domain to become filtered and redirected into junk
folders. As the reputation factor becomes more significant, there may
then be an outright rejection of the message from the forged domain.

Once the message becomes rejected, meaning the reputation is now badly
tainted, the recovery of the domain for email may be extremely
difficult. Such a system is sure to cause the integrity of email
delivery to suffer. Controlling abuse requires the administrator of the
email server to play a critical role. Essentially, it requires that
they control access to the server. Use of an IP address or the
DomainKey signature will directly impact the administrator of the
significant (offending) email server. SPF may not affect such
administrator. Hence a possible lackadaisical attitude regarding their
obligations.

To abate abuse, there must be a low tolerance for abuse, and strong
identifications for the source of the abuse. Once there is any blocking
put in place, it should directly impact the administrator of the email
server causing the problem. SPF may eventually provide feedback to the
domain owner, but the domain owner may have no ability to meaningfully
respond in a timely manner. At that point, they may also have no
ability to recover either.

It is not surprising so little is being said about the implied duties
required to protect domain owners when they publish SPF records, or the
potential for the harm that may result. As far as the email provider is
concerned, the less said the better. A naive domain owner is willing to
risk their reputation without asking for any indemnification from their
provider. At this time, there is no SPF record that can be published
without also requiring the PRA be examined and assured. The many
different mailbox-domains must be limited to those domains allowed for
each authenticated user. With SPF, providers must vet who is allowed to
use a particular domain, and be sure to enforce each and every identity
that _could_ be used in any SPF related reputation scheme.

The "opt-out" scenario described by Sender-ID is really little more than
a ploy to have domain owners publish PRA specific records. This record
strategy is already prone to the Machiavellian "user feedback" button.
Ignoring Sender-ID would be at your peril. At some point, snap.

-Doug

[Hector Santos]

----- Original Message -----
From: "Douglas Otis" <***@mail-abuse.org>
To: "Graham Murray" <***@webwayone.co.uk>
Cc: <ietf-***@imc.org>
Sent: Tuesday, May 31, 2005 3:07 PM
Subject: Re: draft-schlitt-spf-classic-01.txt

Post by Douglas Otis
While
possible, with add restrictions imposed by the email provider, the
domain owner remains completely at the mercy of an email provider's
diligence at _every_ MTA involved in the transport of the message, and
not just those MTAs that have been directly authorized by the SPF
record. A mistake on the part of an email provider, such as
misconfiguration of a firewall, and the domain owner's reputation
suffers.

And how is CSV immuned from these same set of possible routing scenarioes?

Are you saying that once CSV authorizes a submission at the MSA, then there
is no need to further perform CSV during the route and only at the MDA?

What if you have this topology?

MUA ---> MSA1/MTA1 -----> MTA2 ----> MDA3

MSA1 and MDA3 is CVS ready. MTA2 is not.

How does MDA3 handle this using CSV? What is the policy here?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

[Douglas Otis]

While possible, with add restrictions imposed by the email provider,
the domain owner remains completely at the mercy of an email
provider's diligence at _every_ MTA involved in the transport of the
message, and not just those MTAs that have been directly authorized
by the SPF record. A mistake on the part of an email provider, such
as misconfiguration of a firewall, and the domain owner's reputation
suffers.

And how is CSV immune from these same set of possible routing scenarios?

The HELO name would be indicative of the domain administrator running
the MTA, irrespective of the mailbox-domains contained in messages sent
by the MTA. If the MTA is not properly administered, it would be this
MTA and the administrator of this MTA identified by a reputation scheme
that rates HELO names.

Those that would normally send messages over a HELO blocked MTA would be
free to look elsewhere to obtain email services. If the mailbox-domains
were rated and blocked instead, as with SPF, a poorly maintained MTA
could continue to send abusive and even forged emails, but then the
domain owners would find use of their domains blocked, no matter which
other provider they tried. Not fair for the domain owner, nor effective
at preventing abuse. : (

Are you saying that once CSV authorizes a submission at the MSA, then there
is no need to further perform CSV during the route and only at the MDA?

CSV would be checked once for every HELO presented. The basis of any
reputation should be with respect to the administrator. Only the
administrator is in a position to take immediate and knowledgeable
corrective action. Normally an administrator's reputation evaluation
would only need to be done once for any number of messages. Unlike SPF,
which may entail many many lookups, CSV requires just one for its basic
use, and done just once per MTA for a substantial reduction in overhead.
This low overhead makes CSV suitable for protecting network resources.

What if you have this topology?
MUA ---> MSA1/MTA1 -----> MTA2 ----> MDA3
MSA1 and MDA3 is CVS ready. MTA2 is not.
How does MDA3 handle this using CSV? What is the policy here?

CSV offers a means to protect network resources on a name basis. CSV
would permit name reputation accrual for the MTA, rather than just for
its address as done today. Thus updating addresses would not impact the
MTA administrator to the same extent as it does today. As CSV uses the
SRV record, there would be no address maintenance involved in an address
change either. (Beyond the normal A record reassignment of the
interface of course.)

By elevating the network reputation protection service to the name
space, rather than just address space, CSV offers a means to extend DoS
protections for other uses, such as email signatures as described in:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt

CSV also provides a means to establish domain-wide assertions without
the use of wildcards as well. Of course this would be greatly
facilitated by a convention that expects the HELO to resolve to a CSV
record.

If MDA2 claimed to be from a domain that had a domain-wide policy that
required a CSV record (per the SRV Port assertions), then a lack of such
a record would become a basis for MTA3 to refuse messages from MTA2.

There could also be a simple fallback that depends upon an address space
reputation service, instead of name space. Regardless of the use of
addresses or HELOs, there is no expectations that new conventions are
adhered to by each MTA. The HELO name would be authenticated directly,
and would be acting under the auspices of the MTA administrator.

On top of this network HELO name reputation protection scheme, a
signature domain name reputation protection scheme could be constructed.
In either case, HELO or signature domain, the name reputation would
reflect the diligence of the administrator guarding access at each MTA.
Of course, in the case of the signature, this provides valuable end-user
protections, and not network resource protections.

Signature schemes would also assist MTA administrators identify
problematic accounts without unfair assumptions. CSV and Signatures are
fair and safe alternative to path registration.

-Doug

[william(at)elan.net]

Post by Douglas Otis
The HELO name would be indicative of the domain administrator running
the MTA, irrespective of the mailbox-domains contained in messages sent
by the MTA. If the MTA is not properly administered, it would be this
MTA and the administrator of this MTA identified by a reputation scheme
that rates HELO names.

Doug,

People here are not saying that being able to tag responsiblity to MTA is
a bad idea. People are just saying that there are also other ways it
can be done and that MTA responsiblity is one thing while domain owner
responsiblity is another and that both are usefull when making decisions.

Post by Douglas Otis
Those that would normally send messages over a HELO blocked MTA would be
free to look elsewhere to obtain email services. If the mailbox-domains
were rated and blocked instead, as with SPF, a poorly maintained MTA
could continue to send abusive and even forged emails, but then the
domain owners would find use of their domains blocked, no matter which
other provider they tried.

I think what you're trying to argue here that when domain owner is using
shared MTA that does not have strong policies in regards to its network
than it may become target of abuse and abusers may choose to use other
domains maintained by that MTA at random, i.e. its the case of large dsl
provider and user having to use that provider's MTA and is subject to
the MTA being used by zombies located on the provier's networ and zombies
choosing domains of various users (that come through that mta) at random.
Is that what you're worried about?

[Alan DeKok]

Post by william(at)elan.net
I think what you're trying to argue here that when domain owner is using
shared MTA that does not have strong policies in regards to its network
than it may become target of abuse and abusers may choose to use other
domains maintained by that MTA at random,

If an MTA is shared, the reputation would seem to be shared, too.
That's life.

We could require that abuse of a shared MTA by one domain not affect
the reputation of another domain also at that MTA. But we can't use
the HELO field as part of a solution to meet that requirement, as the
only information it presents is the name of the shared MTA.

If the *message* is authenticated, and not the *transport* layer,
then it doesn't matter how the message is transported. But that's
another issue...

Alan DeKok.

[Graham Murray]

Post by Alan DeKok
If an MTA is shared, the reputation would seem to be shared, too.
That's life.

If reputation is that important for a domain owner then they can always run
their own mail server(s) and not use a shared MTA.

[johnp]

I run Postfix on a server, and anyone who wants a seperate MTA can have
a seperate instance of Postfix running just for themselves, with a
seperate IP. The rest of the server facilities are shared. I'm not sure
if sendmail allows seperate instances to run similtaneously like this.

Post by Graham Murray

Post by Alan DeKok
If an MTA is shared, the reputation would seem to be shared, too.
That's life.

If reputation is that important for a domain owner then they can always run
their own mail server(s) and not use a shared MTA.

[Douglas Otis]

Post by Alan DeKok

Post by william(at)elan.net
I think what you're trying to argue here that when domain owner is using
shared MTA that does not have strong policies in regards to its network
than it may become target of abuse and abusers may choose to use other
domains maintained by that MTA at random,

If an MTA is shared, the reputation would seem to be shared, too.
That's life.

I agree with William's statement. With SPF or Sender-ID, reputation
accrual would damage a mailbox-domain owner, and not the MTA
administrator. The mailbox-domain owner may have been singled-out and
forged by some zombied customer, until the victim's reputation is
thoroughly destroyed.

The administrator of a shared MTA must apply mailbox-domain constraints
on both the bounce-address and the PRA for each and every message. This
constraint must limit the domains permitted for the authenticated users
or relayed MTAs. Lack of this domain constraint operation imperils
their customer's domain reputation. I doubt many email providers would
provide a virtual MTA with an isolated IP addresses, just to avoid the
need to assure this mailbox-domain constraint. I have little doubt the
MTA administrator would do nothing, and consider this as not their
problem.

IP address space pressures has caused much of the sharing of IP
addresses for both MTAs and Web servers. One reason to deploy a name
based reputation system, is to overcome the problem of IP address
aggregation affecting so many different domains. The application of
reputation makes domain/user isolation critical for the domain owner.

Post by Alan DeKok
We could require that abuse of a shared MTA by one domain not affect
the reputation of another domain also at that MTA. But we can't use
the HELO field as part of a solution to meet that requirement, as the
only information it presents is the name of the shared MTA.

The lack of HELO validation would not be considered a reason to reject
the message, based on either SPF or Sender-ID validation. Had just the
MTA identifiers, IP address or HELO, been solely utilized as a basis for
accruing reputation, then indeed reputations would be shared by every
domain using the MTA. Then the domain owner could recover use of their
domain by employing a different MTA. Relying upon the MTA identifiers
for reputation accrual provides the MTA administrator an incentive to
aggressively disable abusive accounts. They would maintain diligence by
either monitoring logs for volumes and errors, or by checking abuse
reports. This incentive is real and valuable.

Once an MTA administrator buys the notion that SPF/Sender-ID takes care
of abuse, where reputation no longer affects them directly, they have
less incentive to do the real job of abating abuse before it is sent.
While this may be seen as a great feature by email providers, it should
cause network providers and any domain owner great concern. Abusers
controlling millions of zombies will jump on this weakness, much to the
detriment of mailbox-domain owners sharing an MTA, and that have also
published SPF records. Unless you run your own MTA and are willing to
allow some mail to be lost by those that have forwarding accounts, do
not publish SPF! Consider DomainKeys for now, and then upgrade to DKIM.

Post by Alan DeKok
If the *message* is authenticated, and not the *transport* layer,
then it doesn't matter how the message is transported. But that's
another issue...

Yes it is. That is the reason DKIM is so desperately needed.

-Doug

[Alan DeKok]

Post by Douglas Otis
IP address space pressures has caused much of the sharing of IP
addresses for both MTAs and Web servers.

What's up with 29/8 & 30/8? There are 50M addresses unused.

Post by Douglas Otis
One reason to deploy a name based reputation system, is to overcome
the problem of IP address aggregation affecting so many different
domains. The application of reputation makes domain/user isolation
critical for the domain owner.

In the absence of DNSSec, using DNS names for reputation is a bit
problematic. You're never completely sure that the domain is
currently being controlled by it's owner.

Post by Douglas Otis
Once an MTA administrator buys the notion that SPF/Sender-ID takes care
of abuse, where reputation no longer affects them directly, they have
less incentive to do the real job of abating abuse before it is sent.

I'm not sure there's any technical solution to that problem.

Alan DeKok.

[Douglas Otis]

Post by Alan DeKok

Post by Douglas Otis
IP address space pressures has caused much of the sharing of IP
addresses for both MTAs and Web servers.

What's up with 29/8 & 30/8? There are 50M addresses unused.

IP address conservation has slowed the rate of consumption. Once these
addresses are fully assigned, reliance upon IPv6 becomes required. As
with many things, preparation requires time to phase-in full support.
In the meantime, to allow communities early in their Internet deployment
a reasonable number of IP addresses, some addresses need to be reserved.
If each domain name required a unique address, this reserve would be
quickly exhausted.

Post by Alan DeKok

Post by Douglas Otis
One reason to deploy a name based reputation system, is to overcome
the problem of IP address aggregation affecting so many different
domains. The application of reputation makes domain/user isolation
critical for the domain owner.

In the absence of DNSSec, using DNS names for reputation is a bit
problematic. You're never completely sure that the domain is
currently being controlled by it's owner.

DKIM creates far fewer DNS security concerns compared to SPF which
reduces some of these potential DNS problems, rather than adding to it.
For reasons actually unrelated to DNS, DNSsec should be deployed. While
even DNSsec will not prevent every attack vector, it will expose more
attack efforts. Hopefully, diligence and cooperation prevail in
cutting-off network providers that permit the coordination such
activities.

There is a need to establish a re-assignable ID number to identify those
that trade or use stolen identifiers. By requiring a timestamped query
to a clearinghouse, to return to the requester a relevant static index
(pseudo SSN), would make this information far more risky for the
criminals. The query may also identify abuse attempts. There could be
many re-assignable ID clearinghouses used for various purposes.

Post by Alan DeKok

Post by Douglas Otis
Once an MTA administrator buys the notion that SPF/Sender-ID takes care
of abuse, where reputation no longer affects them directly, they have
less incentive to do the real job of abating abuse before it is sent.

I'm not sure there's any technical solution to that problem.

The simple technical solution would be to _always_ base reputation
accrual upon "Authenticated Senders" and _never_ "Server Authorization."
Going down the list of identifies available that could isolate security
and abuse issues to the accountable administrator, it would be:
- IP Address
- Authenticated HELO Name
- Validated Signatures

You will notice that the mailbox-domain is not in this list. This
mailbox-domain identity is passed from MTA to MTA, and is unrelated to
an accountable administrator. SPF or Sender-ID also makes a false
assumption that the MTA is not shared, or that the MTA administrator
ensures user/mailbox-domain relationships are protected.

I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address or the Purported
Responsible Addresses, as defined in Microsoft's proprietary algorithm.
The penalties should be sufficient to cover loss of the use of the
domain. This SLA should provide a means to verify any allegations of
negligence on the part of the provider. Without this agreement, the
domain owner would be placing their domain's reputation in extreme
peril.

-Doug

[Alan DeKok]

Post by Douglas Otis
Going down the list of identifies available that could isolate security
- IP Address
- Authenticated HELO Name
- Validated Signatures
You will notice that the mailbox-domain is not in this list.

s/this/your/. Not everyone agrees.

I have vanity domains where I'm the only person with mailboxes at
the domain. I *am* the accountable administrator for that domain, and
I would like to be able to state so. I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

Some proposals allow me to do that. The original purpose behind RMX
was exactly that: Hadmut had a vanity domain, and couldn't stop people
from forging messages using that name. Hadmut was also very clear
that not everyone would want to use RMX, but the people who would use
it could protect themselves.

The response then, as now, is that there is absolute opposition to
such proposals. The requirement that we permit ".forward" style MTA's
to use third-party domain names is a requirement that people like
Hadmut and myself cannot prevent others from forging spam using our
names.

Post by Douglas Otis
This mailbox-domain identity is passed from MTA to MTA, and is
unrelated to an accountable administrator.

Ah, yes. If we assume the current behavior is desired, then the
conclusions are foregone.

If, on the other had, we have the temerity to question the existing
assumptions, then the conclusions are questionable, too.

Post by Douglas Otis
SPF or Sender-ID also makes a false assumption that the MTA is not
shared, or that the MTA administrator ensures user/mailbox-domain
relationships are protected.

SPF and related proposals allow the DNS administrator to claim that
the MTA satisfies certain criteria. But this benefit is being turned
around, and claimed to be an accidental, and negative side-effect.

Post by Douglas Otis
I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address

For me, it isn't so much about permission as audit trail. If I
can't prove a particular message using a mailbox address is actually
associated with that address, then I have no idea if the message is
forged or not. Signatures don't help, as anyone can create a
certificate or key for any identity they want.

What matters is the "web of trust", or the relationship. Signatures
*can* help if the certificate for "***@example.com" is signed by the
key for "example.com", and the key for "example.com" is signed by a
known CA. In that case, the signatures are a means to an end, not a
solution in themselves. They make the relationship management easy
and reliable, nothing more.

Alan DeKok.

[Douglas Otis]

Post by Alan DeKok

Post by Douglas Otis
Going down the list of identifies available that could isolate security
- IP Address
- Authenticated HELO Name
- Validated Signatures
You will notice that the mailbox-domain is not in this list.

Not everyone agrees.
I have vanity domains where I'm the only person with mailboxes at
the domain. I *am* the accountable administrator for that domain, and
I would like to be able to state so. I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.
Some proposals allow me to do that. The original purpose behind RMX
was exactly that: Hadmut had a vanity domain, and couldn't stop people
from forging messages using that name. Hadmut was also very clear
that not everyone would want to use RMX, but the people who would use
it could protect themselves.
The response then, as now, is that there is absolute opposition to
such proposals. The requirement that we permit ".forward" style MTA's
to use third-party domain names is a requirement that people like
Hadmut and myself cannot prevent others from forging spam using our
names.

Those accruing reputations based upon evidence of abuse, have no way to
know whether the message was carried over a shared MTA or not, and in
the case of SPF version 1, whether the sender expected the
bounce-address or the PRA be used as a basis for acceptance. If SPF
were used just to reject messages from unauthorized servers, which is
rarely the case due to path registration problems, indeed there would be
far less risk involved when publishing SPF records.

While some domain owners may run their own MTA and permit just their
domain to utilize the MTAs that carry their outbound messages, this
would not represent a typical case. The outright blocking of messages
from unauthorized servers is often not practical either. There will
always be cases where email is lost or refused, when attempting to
create such strict path registrations. Lost messages can be problematic
whether for financial institutions or large network providers.

Recipients are left using a filtering paradigm that attempts to
establish acceptance thresholds for the multiple levels of authorization
presented by SPF. The additional lowered levels of authorization
attempt to convey the likelihood a sender conforms to path registration.
Of course, there is no way to accommodate any forwarding that may
process their message.

While not everyone may agree, strict server authorizations and exclusive
MTAs represent special cases. Even these special cases offer little
benefit in terms of phishing prevention. The recipients willing to
dredge through often extensive path registrations, would be hard pressed
to realize a benefit, when the majority of messages reference open-ended
records, and no reputation is accrued. There is the danger. With SPF,
corner cases will likely find themselves in the junk folder, and those
that permit exceptions with open-ended records, may also find their
reputation damaged. Those that share an MTA may also find their
reputation damaged and should demand indemnification from their
provider.

Post by Alan DeKok

Post by Douglas Otis
This mailbox-domain identity is passed from MTA to MTA, and is
unrelated to an accountable administrator.

Ah, yes. If we assume the current behavior is desired, then the
conclusions are foregone.
If, on the other had, we have the temerity to question the existing
assumptions, then the conclusions are questionable, too.

When today's systems are able to digitally sign messages without
requiring additional hardware, and can do so in the time needed to
dredge through path registrations, you should question schemes that
require wrenching changes to decades old and highly pervasive
architectures. With signatures, you do not need your email provider to
swear they make mailbox-domain restrictions.

Path registration and mailbox-domain restrictions create a very bad
premise for basing a new reputation scheme. This premise suffers two
very serious flaws. It often fails to identify the accountable
administrator, while at the same time expects the administrator to
impose additional expensive limitations on the use of mailbox-domains.
At least warn the domain owner to ensure domain restrictions are in
place by the provider before publishing SPF records.

Post by Alan DeKok

Post by Douglas Otis
SPF or Sender-ID also makes a false assumption that the MTA is not
shared, or that the MTA administrator ensures user/mailbox-domain
relationships are protected.

SPF and related proposals allow the DNS administrator to claim that
the MTA satisfies certain criteria. But this benefit is being turned
around, and claimed to be an accidental, and negative side-effect.

There is nothing provided by SPF that indicates whether 1 or 1000
domains use an MTA or whether any mailbox-domain was initially checked
for that matter.

Post by Alan DeKok

Post by Douglas Otis
I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address

For me, it isn't so much about permission as audit trail. If I
can't prove a particular message using a mailbox address is actually
associated with that address, then I have no idea if the message is
forged or not. Signatures don't help, as anyone can create a
certificate or key for any identity they want.

Either path registration or a key from DNS do not add any new identity
abstractions. Not just anyone can create the path registration for the
domain. Not just anyone can create a key for the domain. Signatures,
unlike path registration, do not depend upon knowing beforehand the path
a message eventually takes, and hence will not break current email
architectures.

Unlike path registration, the private portion of the key is not exposed,
which provides the possibility for a stronger audit trail, than that
available with path registration. The key itself could be used to sign
prior keys, as example. Of course, this is similar to DNSsec.

Post by Alan DeKok
What matters is the "web of trust", or the relationship. Signatures
key for "example.com", and the key for "example.com" is signed by a
known CA. In that case, the signatures are a means to an end, not a
solution in themselves. They make the relationship management easy
and reliable, nothing more.

While a CA would offer improved security, as would DNSsec for that
matter, DKIM relies upon the security of DNS the same as SPF does. I
attempted to illustrate how doing non-recursive key lookups could be
used to establish a key audit, as an interim solution for DNSsec. I
doubt such scheme will be employed, unless some exploit makes such
auditing required. I described it in the
draft-otis-mass-reputation-01.txt draft to improve the chances this
concept would be available if needed.

-Doug

[Frank Ellermann]

in the case of SPF version 1, whether the sender expected the
bounce-address or the PRA be used as a basis for acceptance

__
/ \
| |
|\____/|
( )
| |
| |
| |
__ ( (--) ) __
/ -- \ | |/ -- \ _
| \| | \/ - \
| | | | \
/ | | | | |
/ | |
( \ |
\ \ | / |
\ \ | / |
\ | /
| |
\ /
| |
| |

[Douglas Otis]

in the case of SPF version 1, whether the sender expected the
bounce-address or the PRA be used as a basis for acceptance

Who is really most deserving of this eloquent message?

Care to comment on this message?
http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

Or, how about this message?
http://www.imc.org/ietf-mxcomp/mail-archive/msg05572.html

You are ignoring a reality that Microsoft has usurped the definition of
the v=spf1 record and clearly has this record in their pocket. This is
evidenced by their clout at various email conferences. The "bounce-
address" and not "PRA" version of SPF must be defined by the version 2
record. The sooner SPF advocates accept this, the greater the chances
SPF will not morph into Sender-ID by way of a reputation trap.

-Doug

[Frank Ellermann]

Post by Douglas Otis
Who is really most deserving of this eloquent message?

The verbose variant wasn't suited for a mailing list open
for the public includinng children.

Post by Douglas Otis
Care to comment on this message?
http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

When you say that PRA is incompatible with v=spf1 policies
you're right. That is _old_ news, see also Meng's article:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/8119>

Or Wayne's comment about it:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/8162>

Post by Douglas Otis
You are ignoring a reality that Microsoft has usurped the
definition of the v=spf1 record and clearly has this record
in their pocket.

This is not the case. See below what I'e written to two IESG
members, as far as I'm concerned everybody can read it. Some
days old, the new draft is now -02 and not more -01, bye, Frank

[does draft-lyon-senderid-core-00 obsolete SPF version 1 ?]

No, it is only trying to use several hundred thousands published
v=spf1 policies for the similar spf2.0 scheme. These schemes are
partially incompatible. The PRA is not necessarily related to the
MAIL FROm, that's why MARID first decided to introduce spf2.0/pra,
later adding spf2.0/mfrom - the latter is compatible with v=spf1.

After MARID was closed the SPF community resumed its work on v=spf1,
resulting in the drafts from Mark Lentczner and later Wayne Schlitt.

The Schlitt drafts clearly say that testing v=spf1 policies with
something they were never designed for (like the PRA algorithm) is
NOT RECOMMENDED. It can result in loss of legit mail. This issue
has been discussed on many lists (spf-discuss, MARID, IETF general,
etc.).

The new Schlitt draft -01 (published yesterday) explains the issue
with the NOT RECOMMENDED better. The new wording should make it
clear that of course using the PRA algorithm with any spf2.0/pra
policy is no problem - actually almost nobody in the SPF community
cares about the PRA. But using PRA with v=spf1 will cause havoc.

I'm surprised why there was a note to the RfC editor proposing to
remove the old NOT RECOMMENDED from the old Schlitt draft -00,
while there was no note to remove the SHOULD from draft Lyon -00:

| SHOULD interpret the version prefix "v=spf1" as equivalent to
| "spf2.0/mfrom,pra"

This is plain wrong. No v=spf1 policy was designed to survive a
PRA test. Many v=spf1 policies were published long before MARID,
when Sender-ID was still Caller-ID. A v=spf1 policy is _almost_
equivalent to spf2.0/mfrom (the latter has no HELO check, but it
checks MAIL FROM), but it is incompatible with spf2.0/pra. The
new draft Lyon -01 still has the same serious technical problem.

Bye, Frank

[Alan DeKok]

If SPF were used just to reject messages from unauthorized servers,
which is rarely the case due to path registration problems, indeed
there would be far less risk involved when publishing SPF records.

So... why do "path registration" at all? I'm still confused as to
why it's OK for people I've never heard of to send messages using my
mailbox address.

When I send messages, my outgoing MTA looks up the MX record for the
domain of the destination mailbox, and sends the message to the
specified MTA. Where's the path?

If we had provable senders, and signed messages, then the path
problem would disappear. If the transport layer, and application
message layer are both signed and accountable, then any MTA should be
able to transfer messages for any other MTA, and path problems become
moot.

There is nothing provided by SPF that indicates whether 1 or 1000
domains use an MTA or whether any mailbox-domain was initially checked
for that matter.

Is that a problem? Publishing SPF records indicates that the domain
owner accepts accountabilty for the behavior of the MTA. Who cares if
the MTA has another 10^6 domains, or is run by a
<insert-prejudice-here>, or by a convict, or is in Iraq? The domain
owner states the MTA is accountable, so therefore it is.

This objection to SPF looks a lot like an objection to *permitting*
the domain owner to make such statements.

Alan DeKok.

[Douglas Otis]

Post by Alan DeKok

If SPF were used just to reject messages from unauthorized servers,
which is rarely the case due to path registration problems, indeed
there would be far less risk involved when publishing SPF records.

So... why do "path registration" at all? I'm still confused as to
why it's OK for people I've never heard of to send messages using my
mailbox address.

Excellent questions.

Post by Alan DeKok
When I send messages, my outgoing MTA looks up the MX record for the
domain of the destination mailbox, and sends the message to the
specified MTA. Where's the path?

The possible network addresses of where a message can be delivered for a
specific domain may only be partially resolved in an MX lookup process.
Once a valid network address has been discovered, immediate delivery
would normally be to that network address. Once delivered, the message
may then be passed on to several other locations, before arriving at a
mailbox destination. Often you can not know this path, nor would you
normally care.

For some organizations, the outbound network address used to send
addresses may be unknown, which is the portion of the path that SPF
attempts to register. Organization may sub-contract services, and these
often evolve frequently. For some organizations, the complexity of
their email infrastructure is not readily accommodated in the 100+ DNS
records allotted by SPF.

Post by Alan DeKok
If we had provable senders, and signed messages, then the path
problem would disappear. If the transport layer, and application
message layer are both signed and accountable, then any MTA should be
able to transfer messages for any other MTA, and path problems become
moot.

To some extent you would be correct. There is still a need to protect
network resources, and this entails something other than a signature.
Protection requires authentication, or the integrity of the network
resource protection scheme would prove unsafe and unfair. With email,
only the remote IP address or the HELO offers specific confirmation of
an actual source of a message. Authorization can not be safely used to
infer the source of the message.

Post by Alan DeKok

There is nothing provided by SPF that indicates whether 1 or 1000
domains use an MTA or whether any mailbox-domain was initially checked
for that matter.

Is that a problem? Publishing SPF records indicates that the domain
owner accepts accountability for the behavior of the MTA. Who cares if
the MTA has another 10^6 domains, or is run by a
<insert-prejudice-here>, or by a convict, or is in Iraq? The domain
owner states the MTA is accountable, so therefore it is.

While the domain owner will surely suffer the results of an MTA
administrator's lack of diligence, I would not expect any domain owner
has accepted this accountability. I have heard time and time again,
admonishments that domain owners should ignore concerns in this regard.
SPF somehow magically protects them. A shamefully false statement of
course.

There is even the matter of defining what being diligent entails.
Should the MTA administrator ensure exclusive use of the bounce-address
or does this also include the PRA. There is no warning about publishing
an SPF record that includes the PRA scope. The suggested dummy PRA
record by Sender-ID has already been declared to have limited value in
the future. What then?

Post by Alan DeKok
This objection to SPF looks a lot like an objection to *permitting*
the domain owner to make such statements.

The publishing of these records should include a disclosure as to the
potential negative impact this record may have with the domain's
reputation. It should describe what actions are needed by the provider,
to ensure the domain owner's protection in the all to common case of
shared MTAs.

Importantly, there should be a way to use the SPF record that clearly
indicates what is being assured by the domain owner. The lack of
consensus regarding the version 1 record makes excluding the use PRA
impossible. Depreciate the use of Version 1 and express the scopes
found in version 2. This would permit a means to positively exclude the
use of the PRA. I also see value in being able to exclude the use of
any scope, to permit this record be used for white-listing only, for
example.

-Doug

[Alan DeKok]

Post by Douglas Otis
The possible network addresses of where a message can be delivered for a
specific domain may only be partially resolved in an MX lookup process.
Once a valid network address has been discovered, immediate delivery
would normally be to that network address. Once delivered, the message
may then be passed on to several other locations, before arriving at a
mailbox destination. Often you can not know this path, nor would you
normally care.

But if I deliver a message to the MX that is authoritative for the
domain of the mailbox, the message is *delivered*. It's *done*.
You're assuming that *my* message gets forwarded *from* the domain I
sent it to, and that it's still marked as *my* message.

If it does, I don't see why it's labelled as "my" message. The
historical approach to label it that way is nice historically, but
there appear to be some kind of abuse issues associated with it...

Post by Douglas Otis
While the domain owner will surely suffer the results of an MTA
administrator's lack of diligence, I would not expect any domain owner
has accepted this accountability. I have heard time and time again,
admonishments that domain owners should ignore concerns in this regard.
SPF somehow magically protects them. A shamefully false statement of
course.

Sure. But if they choose to accept that accountability, isn't that
their choice?

Post by Douglas Otis
The suggested dummy PRA record by Sender-ID has already been
declared to have limited value in the future. What then?

They can use a proposal that doesn't have problems.

Post by Douglas Otis
The publishing of these records should include a disclosure as to the
potential negative impact this record may have with the domain's
reputation. It should describe what actions are needed by the provider,
to ensure the domain owner's protection in the all to common case of
shared MTAs.

That's a matter for the documentation of the proposal, not for it's
implementation.

Post by Douglas Otis
Importantly, there should be a way to use the SPF record that clearly
indicates what is being assured by the domain owner.

Of course. Any similar system should have similar assurances.

Alan DeKok.

[Frank Ellermann]

Post by Alan DeKok
if I deliver a message to the MX that is authoritative for
the domain of the mailbox, the message is *delivered*. It's
*done*.

"Final delivery" is something different, I'd say "sent" where
you say "delivered".

Post by Alan DeKok
You're assuming that *my* message gets forwarded *from* the
domain I sent it to, and that it's still marked as *my*
message.

There's no problem, the MX can be a gateway to some fascinating
UUCP forwarding, or forward your mail to an MDA, with several
hops, it's all fine and still MAIL FROM you RCPT TO recipient.

Post by Alan DeKok
If it does, I don't see why it's labelled as "my" message.

Here you're talking about a _new_ recipient with _another_ MX.

That's of course not more your responsibility, and if there is
a technical problem it's definitely not your problem. As soon
as another MX of a third party is involved it's the problem of
the "original" recipient. He could adjust the MAIL FROM - one
of the many ways to deal with his responsibility.

Post by Alan DeKok
The historical approach to label it that way is nice
historically

It is _not_ the historical approach, that's only a legend of
the "bounces-to" camp. Historically each forwarding host added
its name to the reverse path, MAIL FROM @mx3,@mx2,@mx1:you

For obvious reasons that design worked against forged addresses,
mx2 and mx1 were not interested to forward any MAIL FROM you if
they would have to deal with later bounces to you.

That's also the reason why there's a 551 "user not local" code.

When they killed the source routes in 1123 they simply "forgot"
that this is a security loophole for the 251 alias-style of
forwarding - RfC 1123 is 16 years old, nobody could foresee the
disastrous effects of this security loophole in SMTP today.

But when you said (in your LMAP memo) that some LMAP proposals
_change_ the original _semantics_ of the MAIL FROM this is NOT,
repeat NOT, repeat NOT, true.

The MAIL FROM _semantics_ is as it always was since STD 10. And
SPF simply uses it to fix this security loophole in SMTP today,
for those who want it.

Post by Alan DeKok
if they choose to accept that accountability, isn't that
their choice?

Of course. Bye, Frank

[Alan DeKok]

Post by Frank Ellermann
"Final delivery" is something different, I'd say "sent" where
you say "delivered".

Which is part of the confusion. The Simple Mail Transport Protocol
transported the message from origin to destination. That's
"delivery", by at least one standard.

When a FedEx guy hands my receptionist a package, he's "delivered"
it, for all intents and purposes. The receptionist may, in turn,
deliver it to me, but that's a different kind of delivery.

Much of the confusion around these discussions has been a result of
the terms being overloaded, and the participants not qualifying the
context in which they use the terms.

Post by Frank Ellermann
There's no problem, the MX can be a gateway to some fascinating
UUCP forwarding, or forward your mail to an MDA, with several
hops, it's all fine and still MAIL FROM you RCPT TO recipient.

Once the MX for your domain gets the message, any final steps to get
it to your physical mailbox is *internal* to your site. It varies
from site to site in a way that SMTP does not.

Post by Frank Ellermann
It is _not_ the historical approach, that's only a legend of
the "bounces-to" camp.

<shrug> For me, it's all "he said, she said".

Post by Frank Ellermann
The MAIL FROM _semantics_ is as it always was since STD 10. And
SPF simply uses it to fix this security loophole in SMTP today,
for those who want it.

And there's the sticking point: "those who want it".

It's about consent. Two adults consenting to do stupid things is
not something anyone can control or prevent. Yet there's been
significant effort in the SMTP community to do just that.

Alan DeKok.

[Frank Ellermann]

Post by Alan DeKok
Much of the confusion around these discussions has been a
result of the terms being overloaded, and the participants
not qualifying the context in which they use the terms.

Yes, but in essence it's still "simple", and claims that SPF
"breaks forwarding" are an over-simplification, like your
statement "when the MX has the mail it's delivered".

My point is that it can be "forwarded" behind this MX without
"breaking". Only in one special case the receiver would be
in trouble, if he arranges his "delivery" in a way including
an SPF-test behind the first MX.

Post by Alan DeKok
Once the MX for your domain gets the message, any final steps
to get it to your physical mailbox is *internal* to your site

Even in that simple and normal case I have a chance to get it
wrong, secondary MX forwards to primary MX, primary MX tests
SPF, FAIL => your sender policy does of course not permit the
IP of my secondary MX, I forgot to white list this beast.

That's not necessarily "internal", but it's certainly my fault.
You'll get a bounce, and maybe you inform my postmaster@ that I
screwed up. No real problem, shit happens, I'd simply fix it.

BTW, in practice I had this problem only once since April 2004,
apparently receivers testing SPF normally get it right. After
all it's no rocket science, "test a.s.a.p. or don't test it".

Post by Alan DeKok

Post by Frank Ellermann
It is _not_ the historical approach, that's only a legend of
the "bounces-to" camp.

<shrug> For me, it's all "he said, she said".

The "he" was Jon Postel in STD 10, the "she" are later texts.
And "her" claim is that "MAIL FROM" was an error and actually
means "BOUNCES TO" - "history" as you find it in Orwell's 1984.

Post by Alan DeKok

Post by Frank Ellermann
The MAIL FROM _semantics_ is as it always was since STD 10.
And SPF simply uses it to fix this security loophole in SMTP
today, for those who want it.

And there's the sticking point: "those who want it".
It's about consent. Two adults consenting to do stupid
things is not something anyone can control or prevent. Yet
there's been significant effort in the SMTP community to do
just that.

"Philosophical discussions" about design flaws 16 years after
the fact are difficult - with Wayne's time machine I wouldn't
go back to 2003, but jump directly on the desktop of the 1123
editors. With a loaded gun... ;-)
Bye, Frank

[Alan DeKok]

Post by Frank Ellermann
Even in that simple and normal case I have a chance to get it
wrong, secondary MX forwards to primary MX, primary MX tests
SPF, FAIL => your sender policy does of course not permit the
IP of my secondary MX, I forgot to white list this beast.
That's not necessarily "internal",

It's internal to the trust boundary of your domain. I have no way
of knowing that it's a secondary, and you do.

Post by Frank Ellermann
"Philosophical discussions" about design flaws 16 years after
the fact are difficult - with Wayne's time machine I wouldn't
go back to 2003, but jump directly on the desktop of the 1123
editors. With a loaded gun... ;-)

The purpose of philosophical discussions are to obtain a common
agreement as to the intent of the system. If no one can agree on
*why* the system exists, or *what* it's supposed to be doing, then
talking about *how* is a waste of time.

But the discussions I've seen have focussed on "how", and have
steadfastly avoided the "why". The existence proof of the email
system is nice, but a collection of patches over time can result in a
system that no one intended to build. Proof: the spam problem.

Alan DeKok.

[Frank Ellermann]

Post by Alan DeKok

Post by Frank Ellermann
That's not necessarily "internal",

It's internal to the trust boundary of your domain.

Yes, in that sense it's "internal" from your POV.

Post by Alan DeKok
The purpose of philosophical discussions are to obtain a
common agreement as to the intent of the system. If no
one can agree on *why* the system exists, or *what* it's
supposed to be doing, then talking about *how* is a waste
of time.

It's a bit like Euclidian geometry (maybe s/Euclid/Postel/)
- and the bounces-to universe is the non-Euclidian geometry.

You can't say that non-Euclidian geometry is "wrong". It's
perfect, parallel lines cross each other, MAIL FROM actually
means BOUNCES TO, the sum of degrees in a triangle isn't 180,
and the responsible party is not the Return-Path, but hey,
how about fixing it with a PRA ?
Bye, Frank

[Douglas Otis]

Post by Alan DeKok

Post by Douglas Otis
The possible network addresses of where a message can be delivered for a
specific domain may only be partially resolved in an MX lookup process.
Once a valid network address has been discovered, immediate delivery
would normally be to that network address. Once delivered, the message
may then be passed on to several other locations, before arriving at a
mailbox destination. Often you can not know this path, nor would you
normally care.

But if I deliver a message to the MX that is authoritative for the
domain of the mailbox, the message is *delivered*. It's *done*.
You're assuming that *my* message gets forwarded *from* the domain I
sent it to, and that it's still marked as *my* message.
If it does, I don't see why it's labeled as "my" message. The
historical approach to label it that way is nice historically, but
there appear to be some kind of abuse issues associated with it...

Assume you sent a message to a simple exploding list for example. While
you could conclude that once the list server accepted your message, it
now becomes the list server's message. From a reputation standpoint,
this is not desirable from the perspective of the list operator, who
would like any abuse to directly impact those they see as accountable.

The abuse that concerns you has to do with how the accountable entity is
determined. If the accountable entity is determined by some
mailbox-domain having authorized a sending server, then indeed this can
lead to failure or abuse, especially when many domains authorize the
same sending servers. On the other hand, if the accountable entity is
determined by validating a signature using a key published by the
sending domain, then any opportunity for this to be abused is
dramatically reduced.

Assume you send a message to a forwarding account that acts as an alias
for the recipient. You consider the message being forwarded, by having
the recipient altered on the envelope, to be technically a modified
version of your message. Nevertheless, the content of your message
remains unaltered. Where a delivery failure notice must be sent also
remains unchanged to provide the eventual recipient this essential
information.

It makes no sense to alter the information that normally gets forwarded
to satisfy a flawed scheme that infers the source of a message through
server authorization. This is where abuse may occur, as
server-authorization being considered equivalent to
sender-authentication is a scheme that unfairly makes assumptions of
origin.

I see no problem having high thresholds on the HELO or IP address of the
sending server to form a basis for network protection. I see no problem
allowing forwarding or list servers (leaving mail unaltered), and
relying upon signature validation to determine accountable entities as a
basis for recipient protection. However, there is no reasonable method
to base accountability of a message upon the server having been
authorized.

Post by Alan DeKok

Post by Douglas Otis
While the domain owner will surely suffer the results of an MTA
administrator's lack of diligence, I would not expect any domain owner
has accepted this accountability. I have heard time and time again,
admonishments that domain owners should ignore concerns in this regard.
SPF somehow magically protects them. A shamefully false statement of
course.

Sure. But if they choose to accept that accountability, isn't that
their choice?

In the many presentations I have attended, I have yet to hear any
warnings that by publishing an SPF record, the domain owner's reputation
may become damaged beyond their control, regardless of the type of list
published. I have not heard anything beyond a warning there may be some
reputation risk related to publishing an "open-ended" list. Seldom is
this explained to mean either risk some messages being lost when
forwarded in some fashion, or risk readily obtaining a bad reputation.
Of course, even a "close-ended" list can not offer substantial
protection from forgery when the MTA is shared.

Post by Alan DeKok

Post by Douglas Otis
The suggested dummy PRA record by Sender-ID has already been
declared to have limited value in the future. What then?

They can use a proposal that doesn't have problems.

Which proposal is that? It is not draft-schlitt-spf-classic-01, or
draft-lyon-senderid-core-01. These two drafts are in serious conflict,
and the Sender-ID draft claims that server authorization is equivalent
to sender authentication, whether for the bounce-address or the PRA. Do
you really think it is safe to ignore the intentions of Microsoft?

Post by Alan DeKok

Post by Douglas Otis
The publishing of these records should include a disclosure as to the
potential negative impact this record may have with the domain's
reputation. It should describe what actions are needed by the provider,
to ensure the domain owner's protection in the all to common case of
shared MTAs.

That's a matter for the documentation of the proposal, not for it's
implementation.

I hope they consider the outcome of having withheld this information.
Class-actions love deep pockets. : )

Post by Alan DeKok

Post by Douglas Otis
Importantly, there should be a way to use the SPF record that clearly
indicates what is being assured by the domain owner.

Of course. Any similar system should have similar assurances.

Even by obtaining the record's scope, SPF/Sender-ID assumes email
providers are perfect at assuring exclusive use of a mailbox-domain
within this scope. Have you seen any indemnification making this claim?
This scheme is filled with assumptions and false assurances. If you do
not run your own MTA and can assure exclusive access, SPF/Sender-ID is
an extremely risky choice. Unless you are willing to have some messages
go missing, SPF/Sender-ID is an extremely risky choice.

The safer choice is DomainKeys upgraded to DKIM. : )

-Doug

[Alan DeKok]

Post by Douglas Otis
Assume you sent a message to a simple exploding list for example. While
you could conclude that once the list server accepted your message, it
now becomes the list server's message.

I think the word we're missing here is "anthology". Anthologies are
collections of copyrighted works by individual authors, along with an
editor who has a "collection copyright" on the sum total of the work.

One email message, therefore, is an anthology with multiple authors.
One person wrote the text, another person wrote the quoted text (if
any), the mailer wrote some of the headers (message-id, etc), and so
on. Reputation for the collected work impacts all of the authors in
that collection, to varying degrees.

Post by Douglas Otis
From a reputation standpoint, this is not desirable from the
perspective of the list operator, who would like any abuse to
directly impact those they see as accountable.

If I send a copy of a DVD to this list, and this list re-distributes
it, the list owner may be responsible for "contributoy infringement".
Reputation affects both me as author of the message, and the list
owner as distributor.

If we were to require that list owners *not* have their reputation
affected by messages they re-send, then spammers can hide behind lists.

Post by Douglas Otis
The abuse that concerns you has to do with how the accountable entity is
determined.

s/entity/entities/

That's really the crux of my argument.

Post by Douglas Otis

Post by Alan DeKok
They can use a proposal that doesn't have problems.

Which proposal is that? It is not draft-schlitt-spf-classic-01, or
draft-lyon-senderid-core-01. These two drafts are in serious conflict,
and the Sender-ID draft claims that server authorization is equivalent
to sender authentication, whether for the bounce-address or the PRA. Do
you really think it is safe to ignore the intentions of Microsoft?

Nope. And if all of the proposals re so terrible, we should see if
we can come up with another proposal that isn't so bad.

Alan DeKok.

[Douglas Otis]

Post by Alan DeKok

Post by Douglas Otis
From a reputation standpoint, this is not desirable from the
perspective of the list operator, who would like any abuse to
directly impact those they see as accountable.

If I send a copy of a DVD to this list, and this list re-distributes
it, the list owner may be responsible for "contributory infringement".
Reputation affects both me as author of the message, and the list
owner as distributor.
If we were to require that list owners *not* have their reputation
affected by messages they re-send, then spammers can hide behind lists.

This would be a valid concern. On the other hand, if the original
sender could be authenticated, and there was some breach of conduct,
then seeking redress from this original sender would provide a fair
method to deal with such offenses, without directly impacting the list
server. This would also assume the list server would disable access
when warranted. Authentication of the original sender would also
inhibit spoofed messages from invoking errant retribution.

Post by Alan DeKok

Post by Douglas Otis
Which proposal is that? It is not draft-schlitt-spf-classic-01, or
draft-lyon-senderid-core-01. These two drafts are in serious conflict,
and the Sender-ID draft claims that server authorization is equivalent
to sender authentication, whether for the bounce-address or the PRA. Do
you really think it is safe to ignore the intentions of Microsoft?

Nope. And if all of the proposals are so terrible, we should see if
we can come up with another proposal that isn't so bad.

I see DomainKeys, soon upgrade to DKIM, as a step in the right
direction. Until I see the details regarding DKIM, I am unable to
comment what remains to be done. I will speculate there is a need to
introduce a somewhat independent layer of network resource protection in
addition to a signature scheme. This will be especially important in
areas where network connectivity is limited. It is yet to be seen
whether signatures, by themselves, will be enough of a deterrent. My
fear is when they become more effective following wide spread adoption,
signatures will need to be aggressively defended.

-Doug

[Dean Anderson]

I'm still confused as to why it's OK for people I've never heard of to
send messages using my mailbox address.

This is a fallacy of false choice. Its the equivalent of asking if you've
stopped beating your wife yet. The question seems to permit two choices
(yes, you have, and implies you did before; or no, you haven't yet stopped
beating your wife) Its a fallacy because there are additional
possibilities.

The false choice here is that if we don't approve SPF, we choose to permit
people you've never heard of send messages using your mailbox address.
There is no such choice: SPF doesn't prevent anyone from doing that.

Lets try non-fallacy arguments.

--Dean

[Alan DeKok]

Post by Dean Anderson
The false choice here is that if we don't approve SPF, we choose to permit
people you've never heard of send messages using your mailbox address.
There is no such choice: SPF doesn't prevent anyone from doing that.
Lets try non-fallacy arguments.

Where in the question you quoted did I mention SPF? I've looked,
and for the life of me, I can't find it.

Alan DeKok.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson
The false choice here is that if we don't approve SPF, we choose to permit
people you've never heard of send messages using your mailbox address.
There is no such choice: SPF doesn't prevent anyone from doing that.
Lets try non-fallacy arguments.

Where in the question you quoted did I mention SPF? I've looked,
and for the life of me, I can't find it.

Maybe you missed the title: Re: draft-schlitt-spf-classic-01.txt

[Dean Anderson]

Post by Alan DeKok
I have vanity domains where I'm the only person with mailboxes at
the domain. I *am* the accountable administrator for that domain, and
I would like to be able to state so. I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

And just what benefit is there to being able to do this?

I too, have pet peevs: I would like cats to use the toilet--I am sure
there is benefit to that. But I am not so sure it would be worth millions
of dollars and the significant additional harms such as are involved with
SPF.

Abuse targeted at one particular domain is enabled by SPF in spades---its
called 100% blowback.

Alan, you've been subjected to significant mail abuse in the past. I
understand that you'd like to prevent mail abuse. But this abuse isn't
spam, and SPF won't solve the problem of people trying to mailbomb you:
SPF makes it worse. You will get mailbombed by <insert large ISP here>'s
mail servers sending you bounces. This is called blowback. It happens a
little bit whenever mail is forged. SPF can make it happen 100%. It would
be impractical to block <large ISP>'s mailservers, so the SPF blowback
problem is much worse. In your case (and in many cases of email forgery),
the mail is forged in order to generate hate mail and otherwise annoy you.
__You__ are the target. __You__ are being harrassed. Unfortunately, there
is no technical way for you to stop your harrasser's from harrassing you.
It you take away one toy, they will use another. In this case, you are
giving them a new toy that is much worse because it is easier to abuse,
generates more abuse per message, and is harder to prevent abuse.

I am writing a paper on why SPF is fatally flawed, since its proponents
haven't yet addressed or even acknowledged the analysis and flaws
previously raised on IETF MARID working group---and since I've also
recently learned that they have been spreading false rumors about 'why
things did not progress at the IETF MARID working group.' They've been
apparently been telling people that there aren't any technical problems
with SPF, and that things did not progress at the IETF for 'non-technical'
reasons.

--Dean

[Alan DeKok]

Post by Dean Anderson

Post by Alan DeKok
I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

And just what benefit is there to being able to do this?

I thought I had explained. What part of my message was unclear?

Post by Dean Anderson
Alan, you've been subjected to significant mail abuse in the past. I
understand that you'd like to prevent mail abuse. But this abuse isn't
spam,

You've been saying that for a number of years now, and during that
time, have had access to zero pieces of data from my domain.

I've had others[1] look at the evidence, and I've looked at it
myself. No one agrees with your assertions.

Not one.

Your position is based on something called "faith", not "reality".

I'm not saying this to convince you, because I know I can't. I'm
saying it to explain to everyone else reading this that your position
is not one to be taken seriously.

Post by Dean Anderson
In your case (and in many cases of email forgery), the mail is
forged in order to generate hate mail and otherwise annoy you.

How do you know the mind of the spammers? Are you in contact with them?

Alan DeKok.

[1] i.e. multiple people with long-term experience in the anti-spam
community, who've looked at 10^4 source IP's, 10^5 fake addresses "at"
my domain on spam CD's, 10^6 connection attempts, and/or 10^8
delivered messages. No one agrees with you. Not one. Most do agree,
however, that I probably have the worst spam problem in the world.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson

Post by Alan DeKok
I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

And just what benefit is there to being able to do this?

I thought I had explained. What part of my message was unclear?

Post by Dean Anderson
Alan, you've been subjected to significant mail abuse in the past. I
understand that you'd like to prevent mail abuse. But this abuse isn't
spam,

You've been saying that for a number of years now, and during that
time, have had access to zero pieces of data from my domain.

Partly true. I have seen your mail statistics that you posted to the
freeradius list. However, you did not take me up on my offer to assist you
with those attacks, which included setting up an MX forwarder to screen
(and analyze) abuse.

Post by Alan DeKok
I've had others[1] look at the evidence, and I've looked at it
myself. No one agrees with your assertions.
Not one.

Its not credible to claim that a 10Mbs ethernet connection would be
saturated with email (as you reported), to a one-person domain, and that
this volume not be abuse.

Its a common pattern of mailbombing.

Post by Alan DeKok
Your position is based on something called "faith", not "reality".

I think your position is based on something called "willful exaggeration"
and its a well documented problem amoung anti-spam zealots.

I know some of the "experts" that looked at your abuse, and they have been
known previously to be anti-spam zealots, one of which is known to
conducted (or supported) abuse of our relays.

--Dean

[Alan DeKok]

Post by Dean Anderson
Its not credible to claim that a 10Mbs ethernet connection would be
saturated with email (as you reported)

My machine has never had had a 10Mbs connection to the net.

Post by Dean Anderson
to a one-person domain, and that this volume not be abuse.

You're assuming that the people buying the "100 million email" spam
CD's know it's a one-person domain.

Post by Dean Anderson
I think your position is based on something called "willful exaggeration"

<grins> You haven't seen the data, so I must be exaggerating.

Post by Dean Anderson
I know some of the "experts" that looked at your abuse, and they have been
known previously to be anti-spam zealots, one of which is known to
conducted (or supported) abuse of our relays.

I've never made that list public, and to the best of my knowledge,
neither have they.

Alan DeKok.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson
Its not credible to claim that a 10Mbs ethernet connection would be
saturated with email (as you reported)

My machine has never had had a 10Mbs connection to the net.

Your attempts at being coy are rather unbecoming. Please be honest. You
rported on freeradius that your machine used to have colo'd ethernet
connection. You reported on freeradius that your colo ISP asked you to
find service elsewhere because of your spam volume was saturating the
ethernet. [BTW, that alone should tell you that it isn't "normal" spam
volume]

Post by Alan DeKok

Post by Dean Anderson
to a one-person domain, and that this volume not be abuse.

You're assuming that the people buying the "100 million email" spam
CD's know it's a one-person domain.

The addresses have to find their way onto such cd's. If you start getting
mail like you have a million subscribers, then probably something is
wrong, because that doesn't usually happen. The cd creators would seem to
have no interest in putting fake addresses on the CD. [They would plainly
have interest in harvesting addresses, but that doesn't usually result in
thousands or millions of fake recipient addresses to a one person domain]
So either someone must have somehow fooled them into thinking you have
millions of subscribers, or perhaps _they_ have something against you.

But you (and your "experts") are the _only_ case of a one-person domain
that I've ever heard of, that gets this much email and subsequently argues
that it was somehow "normal".

What I _suspect_ is that one of the following is the truth:
you were either playing with harvesting, and got burned,
or someone else was playing with harvesting to burn you,
or someone used a list of open relays or proxies to mailbomb you.

What I _know_ [from your posted statistics and reported info] is that it
was not an ordinary sort of spam load, as you (and your "experts") have
claimed. And I _know_ that some of your "experts" were either involved
with, or at least supportive of those who abused open relays.

Further, as I recall, it stopped eventually, and was intermittent.

Post by Alan DeKok

Post by Dean Anderson
I think your position is based on something called "willful exaggeration"

<grins> You haven't seen the data, so I must be exaggerating.

I have some of the statistics, so yes. it is quite possible to draw
conclusions without the raw data. [that is why they call it data
reduction] Unless, of course, you lied in the statistics you reported.
But if you want to send me the raw data, I'll still take a look... You
shared it with others, and it is all yours, so its up to you.

This isn't the first time for such a statisical surprise. Operators have
previously been surprised before what can be inferred with indirect,
remote telemetry and statistics. The distance to a star, for example.
And no one has ever seen an atom, either. All surprises.

Indeed, A certain network operator I know (Nathan Mehl) is _still_ stunned
about an incident that happened way back in _1994_, where I determined his
news server was overloaded by looking at the times on packets. He had
first denied it was overloaded, and blamed the problem on our connection.
He was quite stunned when I showed him statistics on the connection and
timings on the news packets that indicated his server was overloaded. Only
then did he finally admit that it was overloaded. And others were also
complaining about their servers being overloaded. The problem was solved
by adding additional new server. [though he leaves that final admission
out of his recent retellings, I have most of the email from 1994, as well
as the load statistics. Tapes of home directories are indeed wonderful
devices, and properly stored, hold data for a long time.

[BTW this will go up on www.iadl.org sometime as an example of selective
memory vs defamation: Nathan Mehl was the engineer at BBN Planet. I think
it will go under the section on Chris Neill, it compares and contrasts
with Chris: Nathan can be somewhat forgiven for misremembering facts from
1994 many years later. In contrast, Chris was reporting right after the
event. But neither admits being wrong. [anti-spammers never admit being
wrong even conducting abuse like mailbombing] To summarize: Chris Neill
was a abuse admin with Verio who abused our relays from his desktop. He
was finally fired for this. He wasn't the only abuse admin fired for
abuse, but so far as I know, he is the only one who posted a diatribe
describing what happened to a public mailing list. But like many, rather
than accept responsibility for doing a "bad thing", he blames others (me)
for reporting his abuse. They never "remember" being wrong. And indeed,
no anti-spammer has ever rebuked him for his abuse. Most are sympathetic:
Abuse is OK, so long as its "for the cause". Anti-spammer generated junk
mail is euphemistically called "mailbombing"]

Post by Alan DeKok

Post by Dean Anderson
I know some of the "experts" that looked at your abuse, and they have been
known previously to be anti-spam zealots, one of which is known to
conducted (or supported) abuse of our relays.

I've never made that list public, and to the best of my knowledge,
neither have they.

I'm sure I don't have the _entire_ list. But Chris Parker of
Starnet/Megapop and company seem to be among the ones who said I was wrong
on freeradius. Our relays were subsequently abused by hundreds of IPs
from Starnet, and when I complained, Parker indicated that he would not
act on our complaints because he didn't consider open relay abuse to be
abuse. [which is actually consistent with what he told you about your
incident] It shows their support for abuse. I think we had to block port
25 from all of starnet's blocks. [And in 2003, when the open relay
blacklists shutdown, open relay abuse also stopped. It restarted in March
of this, but very, very lamely.]


--Dean

[Alan DeKok]

You rported on freeradius that your machine used to have colo'd
ethernet connection. You reported on freeradius that your colo ISP
asked you to find service elsewhere because of your spam volume was
saturating the ethernet.

You recall incorrectly.

But you (and your "experts") are the _only_ case of a one-person domain
that I've ever heard of, that gets this much email and subsequently argues
that it was somehow "normal".

I've never said it was "normal".

What I _know_ [from your posted statistics and reported info] is that it
was not an ordinary sort of spam load, as you (and your "experts") have
claimed.

I've never said it was ordinary, and neither have any experts I've
talked to. The description I recall is "Holy f*ck!".

Further, as I recall, it stopped eventually, and was intermittent.

You recall incorrectly. It was never intermittent, and it hasn't
stopped.

[Re: list of anti-spam people who've seen data from my domain ]
I'm sure I don't have the _entire_ list. But Chris Parker of
Starnet/Megapop and company seem to be among the ones who said I was wrong
on freeradius.

Chris Parker has never analyzed spam for my domain.


This is fun! Let's do it again.

Alan DeKok.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson
In your case (and in many cases of email forgery), the mail is
forged in order to generate hate mail and otherwise annoy you.

How do you know the mind of the spammers? Are you in contact with them?

How do economists figure out the purposes and principles of business?
Observation and analysis. It doesn't take rocket science to figure it
out.

http://www.av8.net/SpamTypes.txt

Your spam isn't type 1. It isn't type 2. Wait, Type 3 seems to fit pretty
well.

Type 1 Commercial spammers have anonymous .be or .nu domains, which
prevent return mailbombing. Or they use their own domain. They don't need
to forge your address in the "From:" field. They want you to buy their
product. They comply with CAN-SPAM and don't forge addresses.

Type 2 Fraudsters want people to respond so they can conduct the fraud.
They don't need to forge your address, that would hurt the fraud. They
send out messages, hoping for response. The from address is real. It may
be stolen, but its real, until, perhaps it is turned off in response.

Type 3 abusers are trying to conduct some type of annoyance or extortion
or infection. They want you to get hate mail, they want to annoy you. Or
they want to infect people you know with viruses. They want people to
think the mail came from you or at least from your domain. That is the
point. They can't comply with CAN-SPAM, as they aren't real businesses.
This distinguishes pure abusers from commercial bulk emailers, which is
what the DMA set out to do with CAN-SPAM. And CAN-SPAM has been
very successful at demonstrating that.

--Dean

[and yes, I'm aware that many anti-spammers think that CAN-SPAM has been a
dismal failure. And it has certainly been a blow to their claims and their
world view. But its been a success for the DMA. The anti-spammers were
wrong when they rejected the IEMCC proposal in 1997. Probably, it is
anti-spammers that are generating much of the type 3 abuse---anti-spammers
were generating the open relay abuse, and that was very similar in
characteristic to the current type 3 abuse.]

[Douglas Otis]

Post by Douglas Otis
The HELO name would be indicative of the domain administrator running
the MTA, irrespective of the mailbox-domains contained in messages sent
by the MTA. If the MTA is not properly administered, it would be this
MTA and the administrator of this MTA identified by a reputation scheme
that rates HELO names.

People here are not saying that being able to tag responsibility to MTA is
a bad idea. People are just saying that there are also other ways it
can be done and that MTA responsibility is one thing while domain owner
responsibility is another and that both are useful when making decisions.

To authenticate the mailbox-domain, use a signature. It is unfair to
hold the mailbox-domain owner accountable, when there remains doubt
about who actually initiated the message, as with SPF. Dunning the
mailbox-domain owner for abuse can not be effective, when the source of
the problem is a mystery to them. The only avenue available to the
mailbox-domain owner would involve a discovery process in an expensive
litigation, to force the MTA administrator to produce requisite
transaction logs. Otherwise, the MTA administrator would be obligated
to keep these logs private, and may not be cooperative when the logs
indicate they were negligent in some fashion.

Post by Douglas Otis
Those that would normally send messages over a HELO blocked MTA would be
free to look elsewhere to obtain email services. If the mailbox-domains
were rated and blocked instead, as with SPF, a poorly maintained MTA
could continue to send abusive and even forged emails, but then the
domain owners would find use of their domains blocked, no matter which
other provider they tried.

I think what you're trying to argue here that when domain owner is using
shared MTA that does not have strong policies in regards to its network
than it may become target of abuse and abusers may choose to use other
domains maintained by that MTA at random, i.e. its the case of large dsl
provider and user having to use that provider's MTA and is subject to
the MTA being used by zombies located on the provider's network and zombies
choosing domains of various users (that come through that mta) at random.
Is that what you're worried about?

Only by naming the actual source of abuse, not just finding a name to
blame, would reputation provide a means to ensure the MTA administrator
remains diligent. Only a diligent MTA administrator can be effective at
squelching abuse. The number of techniques used to circumvent security
is many. Two rather obvious concerns would be open-proxy or open-relay,
which have specific dedicated black-hole lists for just these possible
administrative errors. Some of these errors require third-party
real-time verification to isolate the source. Hardly a legitimate duty
to be expected of the mailbox-domain owner.

In addition to normal security concerns, with SPF/Sender-ID, the MTA
administrator MUST apply mailbox-domain limitations based upon
permissions for either authenticated users or an MTA being relayed.
This will cost the MTA administrator support calls. Because SPF depends
upon ambiguous defaults defining which identities are assured within a
message, SPF records may be used as a basis for applying the PRA or the
bounce-address. Therefore, any MTA administrator failing to make the
same limitations for the PRA, as for the bounce-address, place the
mailbox-domain owner's reputation at risk.

The only safe option presently available for the mailbox-domain owner
would be to NOT publish SPF records. Otherwise, the mailbox-domain
owner runs a serious risk of being assumed culpable for any forged
abusive messages that may appear. With these SPF records being very
public, an already far too common nefarious abuser employing the use of
Zombied systems, will also know who they should try to forge. Abusers
may be successful due to an MTA administrator's lapse in applying either
some or all of the expensive mailbox-domain restrictions. Even if the
Zombied system were owned by the actual domain owner, the MTA
administrator is best able to detect abuse to alert the domain owner.

On a per-MTA basis, CSV ensures the administrator is held accountable
for the operation of the server. It is foolish to hold a feckless
mailbox-domain owner accountable. Signatures, while not providing any
network resource protection, do offer a fair and safe method to hold the
administrator accountable from where the message originated. Signatures
can track the mailbox-domain and offer real anti-phishing protections as
well. While there have been some to suggest Sender-ID offers
anti-phishing protection, it is not safe due to reliance on hidden
headers and server authorizations.

To increase the integrity and safety of email delivery, an
identification and reputation scheme needs to be as close to go/no-go as
possible. Otherwise, the junk folder becomes the nemesis of a large
number of gray transactions. It is unfortunate that SPF has four levels
of server authorization. This multilevel aspect has a multiplicative
affect on reputation assessments, as there may be a desire to track each
level separately to form some kind of proprietary fuzzy-logic
aggregate.

As I said when I started my comments, SPF is fundamentally flawed. SPF
and Sender-ID in combination is a disaster. The filtering paradigm used
by SPF to handle its many shades of gray will ensure the problems
created will be intractable. The only means I see to extricate SPF from
making things far far worse, would be to depreciate the use of version 1
SPF records. Recommend that they be removed. For those that don't want
to be trusting an MTA provider to assure their reputation, offer a new
scope called 'ADMIN' to allow SPF to be used for white-listing purposes
only.

Should SPF/Sender-ID reputation schemes become used as promised, there
will be a new industry servicing email forensics to assist a booming
civil discovery process. The harm created will be intractable and
extremely damaging. Domain constraints will cause a loss of customers
and enumerable support calls. SPF/Sender-ID provides two very difficult
paths to choose, when attempting to avoid administrative accountability.
Adjust your budget accordingly, there is no free lunch.

CSV, on the other hand, indicates that you accept administrative
accountability without unfairly foisting this onto your customers. Only
signatures offer an alternative that can safely apply accountability
from where the message initiated.

-Doug

[Dean Anderson]

Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just
now, I see you've been subject to reverse ping floods as well. The
reverse attacks you describe are most telling. These happen when people
send pings with your IP address as the ICMP source IP address. That's why
you get people calling up and saying "your machine is attacking me". They
just see the source IP address in the ICMP packets. But in fact, those
packets originate from the botnet machines. The same ones attacking your
SMTP port. Thats what botnets do.

Your "spam" problem was first reported in January 2002:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Wed, 30 Jan 2002 10:53:15 +0000 (UTC)
From: Miquel van Smoorenburg <***@cistron.nl>
Reply-To: freeradius-***@lists.cistron.nl
To: freeradius-***@lists.cistron.nl, freeradius-***@lists.cistron.nl
Subject: Re: Private email to me

[ The following text is in the "iso8859-15" character set. ]
[ Your display is set for the "ISO-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]

I am no longer accepting private email to my 'striker.ottawa.on.ca'
http://www.striker.ottawa.on.ca/
The domain is on *all* of the spam lists from what I can tell, and
is receiving 400K+ spam emails a day. Even dropping the connection
after the "RCTP TO", and not accepting the message body, it's still
too much. The spam is using 10Mbytes per HOUR of bandwidth, which I
can't afford.

[...]
+++++++++++++++++++++++++++++++++++++++++++++++++++++++



This early exchange was significant:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

So, Alan: Who have you annoyed?

Lots of people, I think. I've had the domain since 1996, or so.
I've always been vocal and opinionated.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++


See http://www.striker.ottawa.on.ca/

Other messages of the time noted that back then this IP was hosted with
Ottawa Carleton Unix Corp (AS26227). I see its currently with UUnet.

BTW, A medium sized ISP with perhaps 20,000 users receives about 400,000
messages per day (spam and ham). Probably should have a T3 or OC3 for that
kind of volume.

A medium sized colo center would host several hundred such domains as
striker.ottawa.on.ca. A virtual host center would probably have several
dozen to perhaps a hundred+ domains on a single machine. Plainly, neither
a colo nor virtual host datacenter going to be able to handle 400K PER
DAY, PER obscure DOMAIN.

It is simply not credible to say that 400K messages per day is normal for
an obscure (no offense) one-person domain: Its an attack. There are other
ICMP-based attacks on your your personal domain as well. In other messages
you describe hundreds or perhaps thousands of hosts doing this. You aren't
the first person to experience such attacks. You're just the first person
to claim (rather obstinately) that they aren't one (or a few users
with a botnet) as this quote of shows:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
And the IP address of *my* machine has changed, along with all of
it's upstream providers.

The issue *is* really that there are lots of different spammers
attacking me.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

While you _insist_ that spammers are just routinely spamming you with an
aggregate 400K messages per day, there is no credible reason to think
that. Instead, you are tangling with a botnet. See
http://grc.com/dos/grcdos.htm for an interesting read on botnet attacks.
And yes, they do "spam"/"mailbomb" you.

There are successful strategies for dealing with botnet attacks. GRC is
one interesting way, reporting abuse is another. Reporting abuse
eventually causes them bots, and that causes them to risk getting caught,
and causes them to lose resources (in the form of bots). Your way, of
trying to pursue anti-spam techniques isn't one of the successful
strategies.

There is no help for you in SPF. If you get 400K messages per second
without SPF, you will still get 400K with SPF. As you pointed out in
November, 2002:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
The bandwidth number I quoted in my previous email worked out to
~2-5 gigabytes a month, for:

EHLO . . .
MAIL FROM: spammer
RCTP TO: no-such-***@striker.ottawa.on.ca
<hangup>

If the messages had been delivered, the total data transferred would
go up by a factor of 10-100 times.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

SPF isn't going to reduce that. Banning spam isn't even going to reduce
that: It isn't commercial spammers doing this. In fact, __nothing__ other
than tracking down the botnets will reduce that.

--Dean

[Alan DeKok]

Post by Dean Anderson
Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just
now, I see you've been subject to reverse ping floods as well.

Not surprisingly, you're missing a key point of information. This
leads you to erroneous conclusions.

FYI: At one point, I added FW rules to the box so that port 25 was
open for 5 of my closest friends, and would send ICMP Port
unreachables to everyone else. While this may not have been the best
thing to do, it caught many idiots.

"port unreachable" != "reverse ping flood"

Post by Dean Anderson
These happen when people send pings with your IP address as the ICMP
source IP address. That's why you get people calling up and saying
"your machine is attacking me".

Port unreachables are sent when their SMTP server tries to connect
to mine. The flood of SMTP sessions from compromised boxes leads to
floods of returning "go away" messages from my box. If they're
idiots, they quickly conclude that I'm attacking them.

This has happened not once, not twice, but multiple times. In every
case, I was in contact with the admins of the compromised box, and
once I convinced them to turn off SMTP, the spam delivery attempt
stopped, and therefore the ICMP messages from my box stopped.

And once they fixed the problem, it didn't re-occur from their site.

Post by Dean Anderson
But in fact, those packets originate from the botnet machines.

In fact, you're wrong. The packets in question originated from MY
machine. I know this, you don't.

Please stop, Dean. It's embarrassing.

Alan DeKok.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson
Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just
now, I see you've been subject to reverse ping floods as well.

Not surprisingly, you're missing a key point of information. This
leads you to erroneous conclusions.
FYI: At one point, I added FW rules to the box so that port 25 was
open for 5 of my closest friends, and would send ICMP Port
unreachables to everyone else. While this may not have been the best
thing to do, it caught many idiots.
"port unreachable" != "reverse ping flood"

You have no basis for concluding that their recieving "ICMP port
unreachable" means that they actually tried connecting to you. This
packet is easily forged.

So there is no reason to think they are trying to send you spam. I did see
that you thought they were, __based on their logs__ (_Their_ logs have no
relevance to your claim)

Plainly, __their logs__ of ICMP unreachables don't mean they sent you
connections. You can't be that stupid. This is obstinancy.

If __they__ were sending you thousands of spam connections, and getting
thousands of port unreachables back, they would first notice the
additional CPU load on their server due to the many processes attempting
to connect to you. They would next notice the equally large number of TCP
SYN packets coming from their server. Apparently, they didn't find this,
and so the contacted you.

Now possibly one person would notice Unreachables, and not look to see if
they were sending SYNs. But you indicated that not just a few, but _MANY_
people made this same "mistake". The law of numbers suggests that many
people would not make such a simple mistake.

Further, To prove your claim, __you__ would need logs indicating that they
actually tried connecting. Where are the SYNs from their server? But you
have no such specific logs, or don't claim you do in those cases.

Just another demonstration of bad logic and irrationality.

But once again, you are ___still___ getting ___ABUSE___

This is not routine spam, as you keep insisting. Anti-spam techniques will
not stop people whose goal is abuse.

Spammers aren't calling you complaining that you should not to send them
ICMP unreachables. What lunacy


--Dean

[Alan DeKok]

Post by Dean Anderson
You have no basis for concluding that their recieving "ICMP port
unreachable" means that they actually tried connecting to you.

As I said, how about watching the packets go out of my box?

Post by Dean Anderson
So there is no reason to think they are trying to send you spam.

Other than the umpteen connections/s to port 25 on my machine. No,
no reason to think they're trying to send me spam.

Post by Dean Anderson
If __they__ were sending you thousands of spam connections, and getting
thousands of port unreachables back, they would first notice the
additional CPU load on their server due to the many processes attempting
to connect to you. They would next notice the equally large number of TCP
SYN packets coming from their server. Apparently, they didn't find this,
and so the contacted you.

I count at least 3 assumptions in that paragraph.

Post by Dean Anderson
Now possibly one person would notice Unreachables, and not look to see if
they were sending SYNs. But you indicated that not just a few, but _MANY_
people made this same "mistake".

Read the web page. It's "a steady trickle". More than one, and
less than 10.

Post by Dean Anderson
Further, To prove your claim, __you__ would need logs indicating that they
actually tried connecting. Where are the SYNs from their server? But you
have no such specific logs, or don't claim you do in those cases.

I have the data, you don't. I'm sorry that this upsets you.

Post by Dean Anderson
Spammers aren't calling you complaining that you should not to send them
ICMP unreachables. What lunacy

Exactly. I never claimed that.


At this point, I have to ask: Are you for real, Dean?

Alan DeKok.

[Dean Anderson]

Post by Alan DeKok

Post by Dean Anderson
You have no basis for concluding that their recieving "ICMP port
unreachable" means that they actually tried connecting to you.

As I said, how about watching the packets go out of my box?

1) Having an outbound packet rate, as you describe, doesn't indicate that
they sent you SYN packets. It is possible that your machine is
compromised, and that it really is attacking them.

2) It is possible that you received SYN packeets that weren't from them.
Forged SYN packets are common type of attack.

3) Merely having an outbound ICMP packet rate doesn't mean that the
packets they got came from your system.

4) It is possible that their system is compromised.

All of these are more likely than your insistence that they are spammers
asking you not to send them ICMP packets.

With this in mind, lete look again at your claims: (from
www.striker.ottawa.on.ca)

**1. Their firewall is misconfigured. (Blocking ICMP's is wrong.)

Blocking __all__ ICMP is probably wrong. There is only one ICMP packet
that shouldn't be blocked, and there is currently an attack which makes it
reasonable to block even that turn. So blocking the ICMP port unreachable
packet type is not wrong. http://www.av8.net/ICMPTypes.txt

**2. They're trying to send me spam, and complaining when they can't.

This is just irrational.

**3. They don't understand how networks work, or how to set up their
machines.

Their machines are probably set up correctly. But if they aren't, you
haven't shown any reason that they aren't.

**4. Words cannot describe their incompetence.

The acts you attribute to them are entirely rational and show no
incompetence on _their_ part.

Competence is the ability to solve common problems in your field of work.
A common problem for an IT professional might have to solve is analyzing
an attack. What should a competent professional have done in Alan's
situation? Lets look at what should happen:

Sysadmin calls Alan, and says: "Your system is attacking me"
Alan should say: "What makes you think that?"
Sysadmin says: "I'm getting loads of ICMP messages from your IP."
Alan should say: "What's your IP? I'll take a look"
Sysadmin tells him IP.
Alan grabs packets to and from that IP

[now we have some options, depending on what Alan finds]

Option 1: Alan found packets to/from that IP

Option 1A: Alan found SYN Packets from their IP and ICMP packets to it
Alan says: "I'm seeing SYN packets from your IP. Do you see that?"
Option 1A1: Sysadmin sees it
Sysadmin says: "Yes. Hmm. That's weird"
Alan: "OK. Could you block SYNS to my IP until you fix it?"
Sysadmin: "Sure".
Option 1A2: Sysadmin doesn't see anything
Sysadmin says: "No SYN packets here."
Alan says: "Hmm. Somebody may be forging SYN packets from your IP.
I'll contact my ISP and see if we can trace it down. In the
meantime, I'll block ICMP going to your IP.
Sysadmin says: "Thanks for taking care of the problem"

Option 1B: Alan found ICMP but no SYN Packets
Alan says: "I'm just seeing ICMP packets to your IP. But that's
strange; I don't see any SYN packets. Hmm. I seem to have
a compromise on my box. I'll block ICMP to your IP until
I get it fixed."
Sysadmin says: "Thanks for taking care of the problem"


Option 2: Alan didn't find packets to or from that IP

Alan says: "I don't see anything to or from your IP. It seems that
our IP has been forged in the ICMP packet."
Sysadmin says: "Ok, thanks. I'll contact our upstreams to trace
the traffic. Thanks for you help."

So now we know what should have happened, lets postmotem what happened:

Alan said that no one should contact him because they are reciving ICMP
from his IP. Alan says on his page that anyone contacting him about this
is incompetent. Alan says they are spammers complaining about his ICMP.
Alan says he convinced some to send him _their_ logs. Their logs don't
prove Alan's claims.

Indeed, none of Alan's claims are supportable.

Alan didn't go through any of the steps listed above; He didn't document
them. To demonstrate his own due diligence, he would need to report what
he found.

So, it Alan's competence that's in question. Not the competence of the
people who called him to complain about the ICMP packets apparently coming
from his IP address.

And as already shown, his claims about blocking ICMP are also incorrect.
Alans failure to understand common practice reflects badly on competence
as an IT Professional.

Post by Alan DeKok

Post by Dean Anderson
Further, To prove your claim, __you__ would need logs indicating that they
actually tried connecting. Where are the SYNs from their server? But you
have no such specific logs, or don't claim you do in those cases.

I have the data, you don't. I'm sorry that this upsets you.

You don't make any claim that you gave them your logs. So I don't think
you did. Whether or not you actually have that data is irrelevant. You
didn't use it to make your case to them, and you can't make a rational
case without it. I don't need to see your data to conclude that your
argument is unsupported.

I'm not upset to not have your data. You just seem to be stretching the
assertion that nobody can make any conclusions without it. But that's just
wrong. Deductions can be made, given what you have revealed.

Post by Alan DeKok

Post by Dean Anderson
Spammers aren't calling you complaining that you should not to send them
ICMP unreachables. What lunacy

Exactly. I never claimed that.

You did, and you have been: Point 2 on your list:

2. They're trying to send me spam, and complaining when they can't

Further, you also keep asserting that spammers are routinely spamming you,
and you deny my assertion that you are being abused by people who seek to
annoy you.

My assertion (since 2002) has been that this is an attack. It is not
"spam". It is meant to annoy you.

Post by Alan DeKok
At this point, I have to ask: Are you for real, Dean?

You are the one pursuing an irrational position well beyond the point of
making a credible claim. It is no longer credible to think that you belive
what you say.

[Alan DeKok]

Post by Dean Anderson
4) It is possible that their system is compromised.

When I talked with these people, the SYN's & ICMP's all stopped
after they claimed to have fixed their systems.

This would lead any reasonable person to conclude that their system
was compromised (as I said), that the source and destination of SYN's
& ICMP's was exactly what they appeared to be (as I said), and that no
botnet was involved (as I said).

Post by Dean Anderson
[now we have some options, depending on what Alan finds]

In those options, you leave out the one option I've been telling you
repeatedly is what happened: their machine really was compromised, and
all of the traffic was exactly as it appeared, with no botnets or
forgeries.

Post by Dean Anderson
To demonstrate his own due diligence, he would need to report what
he found.

I have no responsibility to show my logs to you, or to anyone else
on the planet.

Post by Dean Anderson
Whether or not you actually have that data is irrelevant. You
didn't use it to make your case to them,

I didn't need to. They could independently verify for themselves
that their machine was compromised, was sending spam, and that their
machine was sending loads of TCP SYN's to my machine. They aren't
spammers because they aren't *intending* to send spam, it's a
side-effect of their network misconfiguration.

I'm surprised that the one realistic interpretation of the events is
the only one you cannot admit might have happened.

I won't respond to the rest of your comments about competence and
credibility. The evidence speaks for itself.

Alan DeKok.

[Dean Anderson]

It is interesting what you skipped.

I didn't say you needed to show logs, but your coyness with the logs is,
well, interesting. But you do need to describe what happened, and what
steps you took. And you did describe it. However, the description isn't
sufficient to justify any of the conclusions you assert. None of your 4
assertions hold water.

Whether you _talked_ to a few or not makes no difference. A few might have
been compromised. They all _might_ have been compromised. So what. That a
few are compromised doesn't mean _all_ were compromised. Each has to be
handled separately. It is quite reasonable for them to call you. Yet you
assert it was unreasonable, and proof of their incompetence. And I
_doubt_ very much that you were pleasant or reasonable with any of them:
You think they are spammers complaining about getting ICMP unreachables.

If you thought they were compromised, there would be no point in asking
them for logs. You would simply ask them to check to see if they are
sending you SYNs. But you didn't do that. No, you asked them to see their
logs: "what? I can't possibly be sending you unreachables. Send me your
logs." Helpful? Hardly. But you wouldn't want to be helpful to a spammer
complaining about getting unreachables, now, would you? No.

And if several _were_ compromised and attacking the same machine (it would
take more than a few to generate the traffic you describe), it suggests
that they were exploited by a botnet. When multiple sites are exploited,
and all attack the same host, that's a good sign of a botnet operation. So
your assertions that no botnet was involved is just completely, willfully,
obstinately unsupportable. Botnet's change tactics once in while. That's
one reason you have to treat case separately. It may send SYNs today, and
forged packets tomorrow.

And there is _still_ no evidence that any of the people that contacted you
had any network misconfiguration. To the contrary, your assertion that
blocking ICMP Unreachables means network misconfiguration is untrue.

Your railing against them is simply unreasonable and irrational.

But, of course, there is no way that you can be convinced you are wrong.
Just like Chris Neill and many other ultra-radical extremists: You never
admit wrongness, no matter how overwhelming the evidence. Even when Chris
Neill was FIRED for his abuse and investigated by the FBI as a result,
Neill __still__ didn't think he was wrong. Evidence of wrongness doesn't
get much more overwhelming than that.

So, there is little point in further discussion: You aren't or willing to
rationally address any issues. That's fine: Think what you want. But I
have to jump in once in a while to debunk such claims.

--Dean

Post by Alan DeKok

Post by Dean Anderson
4) It is possible that their system is compromised.

When I talked with these people, the SYN's & ICMP's all stopped
after they claimed to have fixed their systems.
This would lead any reasonable person to conclude that their system
was compromised (as I said), that the source and destination of SYN's
& ICMP's was exactly what they appeared to be (as I said), and that no
botnet was involved (as I said).

Post by Dean Anderson
[now we have some options, depending on what Alan finds]

In those options, you leave out the one option I've been telling you
repeatedly is what happened: their machine really was compromised, and
all of the traffic was exactly as it appeared, with no botnets or
forgeries.

Post by Dean Anderson
To demonstrate his own due diligence, he would need to report what
he found.

I have no responsibility to show my logs to you, or to anyone else
on the planet.

Post by Dean Anderson
Whether or not you actually have that data is irrelevant. You
didn't use it to make your case to them,

I didn't need to. They could independently verify for themselves
that their machine was compromised, was sending spam, and that their
machine was sending loads of TCP SYN's to my machine. They aren't
spammers because they aren't *intending* to send spam, it's a
side-effect of their network misconfiguration.
I'm surprised that the one realistic interpretation of the events is
the only one you cannot admit might have happened.
I won't respond to the rest of your comments about competence and
credibility. The evidence speaks for itself.
Alan DeKok.

[Dean Anderson]

Post by Alan DeKok
In fact, you're wrong. The packets in question originated from MY
machine. I know this, you don't.

Lets stick to the facts that were posted in 2002, so that you don't change
the facts as we go along. If your description of facts in 2002 was
insufficient, then I am fully justified in not believing you, and drawing
conclusions from the facts you presented, regardless of what the actual
god-known truth of the matter is.

You didn't indicate that your machine was sending this traffic on your web
page, in 2002. You just indicated that they claimed to have received
packets, and that you convinced them to send logs. That fact that you
would need to convince them to send logs suggests you denied their claims
that you were sending these packets. Otherwise, why would you want their
logs?

Your logic fails: Recieving an ICMP port unreachable doesn't imply the
four things you listed:

=================================================================
Even worse, there have been a consistent trickle of complete shithead
messages from alleged "sysadmins", saying "Your machine is attacking me!"
When they're convinced to send firewall logs, they send logs which show
them receiving 1000's of ICMP port unreachable messages. This says a few
things:


1. Their firewall is misconfigured. (Blocking ICMP's is wrong.)
2. They're trying to send me spam, and complaining when they can't.
3. They don't understand how networks work, or how to set up their
machines.
4. Words cannot describe their incompetence.

In short, if you see your machine getting hammered by ICMP packets from
this IP, it means you have to fix your system. Don't call me. Don't call
my ISP. Don't make stupid threats about me trying to "hack" into your
machines. If you do, then I will call the FBI (or whatever government body
is intimidating to you), and inform them that you are a criminal hacker.
They will believe me, not you.
=================================================================

None of what you claim follows from the fact they got ICMP unreachables.

You'll tell the FBI they are criminal hackers? The FBI will believe you,
not them?


--Dean