Hi Greg Connor, hi John Warren,
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
I think my point, which I didn't state very clearly, is that SPF breaks
forwarding (which we all knew) and SRS is not being well-received. So,
perhaps some kind of whitelisting will always go hand-in-hand with spf
v1.
John Warren [John(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us] com wrote:
The forwarders just need to use their own e-mail address in the "MAIL
FROM" and everything will work without any changes. Everyone is making
this just too complex when the solution is already there.
Exactly. Why do so many people think that SPF breaks forwarding, while what so
many self-proclaimed "forwarders" do is in fact "relaying"? I don't think
SPF's handling of forwarding is broken. I think calling "relaying"
"forwarding" is broken.
SPF really doesn't break forwarding, it only breaks relaying from *untrusted*
relays.
Although I agree that it will be far from trivial, I really think forwarders
should fix their software instead of demanding that they be tolerated
continuing to use it forever at the expense of address forgery victims.
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
SPF also has its flaws. Forwarding is one. Single-minded devotion to
the envelope sender as the end-all and be-all of verification is
another. I don't think it's going to take long for spammers to realize
that all they need to do is spit out something different in the
envelope sender that doesn't appear anywhere in any header, and it
passes right through SPF, even if the Sender: and From: are both
bgates(_at_)microsoft(_dot_)com(_dot_)
[...]
Also, any approach that pays no attention to headers at all will be of
limited benefit to users. I see those as pretty big targets for SPFv2
to try and fix.
SPF is not about matching the envelope sender against message headers. (Or am
I misunderstanding you again?) I will quote Ralf Doeblitz here:
Ralf Doeblitz <list+spf-discuss(_at_)doeblitz(_dot_)net> wrote:
[...] SPF will force spammers to use one of their own
domains fpr the envelope sender. No matter what the user would see in
the message, we will have a valid domain that belongs to the spammer
(or at least its owners allows sending spam), so we can use this to
block spam in the SMTP dialog. Blacklisting domains will be possible
again.
So it doesn't matter how much the content of the message is verifiable -
the fact that we can reliably use the envelope information to filter
spam against blacklists will be enough, IMHO.
I mostly agree with that. Still, like Greg Connor seems to imply, I think that
forgery of the "Sender:" field (or "From:", if "Sender:" is missing) should be
addressed if at all possible, as these fields are usually the only "origin"
address fields displayed by MUAs -- "Return-Path:" isn't. Maybe this is what
PGP/GPG or S/MIME is suited best for, I'm not sure.
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
Again, I'm certainly not saying that SPF is flawed.
Oh, yes, you are! See the first words of the second paragraph above I quoted
from your message. ;-)
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
SPF is going to find itself (or has already found itself) in direct
competition with other proposals that do use headers. Most users don't
know what an envelope sender is or where to find it in the message.
In competition with regard to which goals? Fighting spam? This is not the
primary goal of SPF. If other technologies do check headers, while SPF checks
the envelope sender, I think they will much more probably complement each other
than they will compete.
As a big SPF supporter, I'm certainly not suggesting that the envelope
sender approach is bad -- far from it. I'm just saying that we need to
be aware of headers in some respect.
Why? To fight spam? No, see above. To fight address forgery? Yes, to a
degree -- although SPF shouldn't care about the headers, the problem of
"From:"/"Sender:" forgery should still be addressed, but there may be better
tools than SPF to do that; see above.
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
Julian Mehnle wrote:
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
Solution 2. Modify SPF to not use Mail-From
Let's call this the "SPF V2" approach. SPF doesn't work like this now,
but in the future if SPF is modified, then it may be possible to make
Mail From go back to its original meaning (that is, who should receive
non-delivery notifications) and SPF will work its magic on the
appropriate headers.
If you really think that SPFv2 should take the envelope from/sender as
"where to send DSNs" only, then you should also say that we shall stop
the distribution of SPFv1 ASAP, otherwise it's no use. [...]
Please don't put words in my mouth. No, I'm not saying that.
I re-added your original statement above. You were clearly implying that it
would be desirable "to make Mail From go back to its original meaning (that is,
who should receive non-delivery notifications)", so yes, you were saying that.
The "we shall stop the distribution of SPFv1 ASAP" I added is only the logical
consequence of what you were saying.
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
If SPF causes relatively little pain for spammers, and much more pain for
forwarders, administrators will find themselves looking at alternate
proposals. If that happens, let's be ready with v2.
No, causing pain to spammers is not a primary goal of SPF. I don't think
trying to turn SPF into the "Final Ultimate Solution to the Spam Problem" just
to fight other (explicit) anti-spam proposals would be a wise thing to do.
John Warren [John(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us] com wrote:
On 25 Jan 2004 at 10:24, Julian Mehnle wrote:
MUAs will usually also show "Sender:", and if they don't, they're
broken. So one option would be to require MTAs to put the envelope
sender into the "Sender:" field, overwriting or renaming it if it
already exists. That way, MUAs would display the envelope sender.
NO, NO, NO, NO, Don't even thing about this. I stated this one in error
but the sender is NOT to have a copy of the "MAIL FROM". The correct
header field, as stated in the RFCs, is the "Return-Path". It's already
in the RFCs so don't even think about changing it since it would NEVER
get through.
Given that the "Sender" is very likely to be the same as the "MAIL
FROM" but it does not have to be.
I'll need to take a closer look at the RFCs, but you're probably right in that
"Sender:" and "Return-Path:" have separate meanings. Still, I think this is a
flaw in the RFCs, not only in their wording, but conceptually. There's a
definite problem with forgery of the "Sender:" field (or "From:", if "Sender:"
is missing), see what I wrote below my quote of Ralf Doeblitz above.
PS, Greg Connor:
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
It's entirely possible that I communicated poorly, but I don't believe I
have a "serious misconception". Please do me the favor of giving me the
benefit of the doubt.
[...]
Again, I am answering/partially agreeing with Meng's question; please
don't jump on me too hard. You and I agree more than you might think.
[...]
Also, you referred me to the archives twice in this message, which is
interesting since you seem to have joined the list a bit more recently
than I. Please try to be respectful rather than patronizing. The
archives will show some examples where I fundamentally disagree with a
couple different people and manage to do so respectfully.
I sincerely apologize for my harsh tone. I was angered a bit that the "SPF
needs to look at the headers" discussion started once again, despite so many
good arguments *against* it were given before. Although you still haven't
convinced me otherwise, you are absolutely correct that I should have reacted
much more respectfully. I'll work on it in the future.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)���v¼����ߴ� �1I�-�Fqx(_dot_)com