On Thu, Feb 19, 2004 at 09:18:12PM -0500, Hector Santos wrote:
Anyway, thats my take on this. :-)
In _that_ you are right. That doesn't mean the problem is in SPF.
I will try to explain my PoV using your reply:
You mean you can treat it was a "no decision" to be made, i.e, you can
not
reject. A pass can not be trusted. More testing maybe warranted.
If the sending entity (the domain, not the user) tells you the host is
under control of said entity, you should be able to trust the message
envelope. The return-path _is_ valid.
SPF only validates the domain part of the return path, not the user part of
the return path.
Indeed. So you know who to complain to, or which domain to block, when
it becomes clear the domain is doing something wrong.
So for example, a SPF compliant spammer can issues return paths:
knownuser(_at_)spf-spammer,com
unknownuser(_at_)spf-spammer,com
The domain houses a spammer. I don't care what the user part du jour is.
If the domain does not protect me, the receiver, I will block the entire
domain. Problem gone.
As long as the spammer uses its own domain part, everything is fine.
A bounce to "unknownuser(_at_)spf-spammer(_dot_)com" will result in a double
bounce.
A bounce to "otheruser(_at_)spf-spammer(_dot_)com" (a joe-job) is no problem
either.
Not for me, that is. I am bouncing to the right domain, it's their task
to control their users.
We have an CBV system which proves all this. Validating the machine is not
enough. Its that simple.
Again, that is your opinion.
Bounces are not evil. Bounces are a necessary part of todays email.
Without SPF, you have no way of knowing (for sure) if the bounce is
directed at the true author of the message. With an SPF-pass, you
know with a reasonable certainty the return-path is valid.
Not so, as I shown above. The spammer can use SPF to validate the machine
and still use a bad user name as part of the complete return address.
For spam havens, I couldn't care less. Real providers will control their
own users (so the problem goes away). Cable-modem providers, well... sigh.
SPF-pass: 100% certain the message is legitimate
SPF-fail: near to 100% certain the message is bogus
No. The opposite
SPF-fail: 100% trust in rejection
SPF-pass: 100% certainty in the MACHINE, not the user or message.
Don't focus on the user. The local part is the problem of the provider.
You are dealing with the domain.
SPF-softfail: message likely to be bogus, but far less than 100%
I agree, especially when you consider the ultimate intent of the SPF record
to be switched to a fail fallback. But you can't make a decision, so you
need to still apply further scrutiny on the transaction.
I can (and will) make a decision. SPF is not a blacklist-protocol.
SPF-unknown: as if SPF were not there
same as SPF-pass, SPF-softfail, or nothing there.
Unless you open your mind and understand that this statement is false, you will
have a hard time understanding SPF. The three results are completely different
and should be treated different.
SPF is NOT a replacement for other mechanisms available to you. Nobody said
so. Don't argue from this perspective.
SPF says in Section 3. SPF Record Evaluation
An SPF client evaluates an SPF record and produces one of seven
results:
...
Fail (-): the message does not meet a domain's definition of
legitimacy. MTAs MAY reject the message using a permanent
failure reply code. (Code 550 is RECOMMENDED. See RFC2821
section 7.1.)
This is protocol level dynamic SMTP rejection. Therefore there is no
Received-SPF requirement.
Are you sure you know the difference between MAY, SHOULD and MUST ?
I don't think so.
There _is_ a difference. Softfail will give me, the receiver, a chance
to let you, the author, know you are doing something wrong.
(or maybe the domain owner is wrong, in which case you, the author, should
contact your provider).
The only different is a difference in "information" but has no direct
correlation to nothing you can trust! But even then, look at what you just
done, you care creating a bounce and you are assuming the bounce address is
valid when you only checked the domain, not the user part of the address.
Indeed. I prefer not to generate bounces at all. When I MUST, it is not
to tell someone "you have a virus on your M$computer".
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags