Mailing List Archive

On Mon, 2006-03-27 at 11:18 -0500, Mark Jeftovic wrote:
> I've always thought that the lack of viable SRS functionality has been a
> major factor impeding the adaptation of SPF. Without it, SPF is just a
> half-solution.

That's true -- SPF without SRS isn't a proper solution to anything.

But stop and think about what happens when/if SRS _is_ ubiquitous -- all
hosts rewrite the reverse-path to include a domain or hostname of their
own when they send a mail on, so SPF has become fairly much equivalent
to CSV.

So you've introduced all this breakage for no real benefit. You might as
well have adopted CSV instead of SPF in the first place.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 27 Mar 2006, David Woodhouse wrote:

> On Mon, 2006-03-27 at 11:18 -0500, Mark Jeftovic wrote:
> > I've always thought that the lack of viable SRS functionality has been a
> > major factor impeding the adaptation of SPF. Without it, SPF is just a
> > half-solution.
>
> That's true -- SPF without SRS isn't a proper solution to anything.
>
> But stop and think about what happens when/if SRS _is_ ubiquitous -- all
> hosts rewrite the reverse-path to include a domain or hostname of their
> own when they send a mail on, so SPF has become fairly much equivalent
> to CSV.

> So you've introduced all this breakage for no real benefit. You might as
> well have adopted CSV instead of SPF in the first place.

No, CSV (HELO identity) often has many ids to one MFROM id. And in the
case of virtual domains, there can be many MFROM ids to one HELO id.
They are different namespaces.

Furthermore, with SPF, you can:

a) not use SRS for forwarding (why should I forward to lusers who
check SPF but can't do it right? I understand that it is different for
a domain whose business is forwarding.)

b) just publish SPF records for your HELO domains and ignore MFROM.
Presto - CSV with a slightly uglier syntax, but much wider implementation.

SPF is arguably uglier, but does everything CSV does and lots more.
It is entirely opt-in with optional features - so if you don't like parts of
it, don't use them.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> That's true -- SPF without SRS isn't a proper solution to anything.
>
> But stop and think about what happens when/if SRS _is_ ubiquitous -- all
> hosts rewrite the reverse-path to include a domain or hostname of their
> own when they send a mail on, so SPF has become fairly much equivalent
> to CSV.
>
> So you've introduced all this breakage for no real benefit. You might as
> well have adopted CSV instead of SPF in the first place.

Are you saying that (1) CSV does things that SPF can't do, or (2) CSV
without SRS isn't a proper solution to anything either, or (3) misdirected
bounces are not a problem that requires a solution?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKFbqwL7PKlBZWjsRAr4TAKDoQXp2JmYsEuL8ByHaTJ2MjSUj5wCfRvy8
ZH0oSyBbz8mczL7wtIev7R0=
=SAok
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 2006-03-27 at 21:19 +0000, Julian Mehnle wrote:
> Are you saying that (1) CSV does things that SPF can't do, or (2) CSV
> without SRS isn't a proper solution to anything either, or (3)
> misdirected bounces are not a problem that requires a solution?

No, CSV doesn't do anything that SPF can't do -- except perhaps for
being compatible with email in the real world. But it doesn't solve any
problems that SPF doesn't; only the one that SPF tries to pretend
doesn't really exist.

And no, neither CSV nor SPF are total solutions to the spam problem,
because each needs to be coupled with some kind of reputation database
for that. CSV and SPF only really offer you a way to authenticate the
entity responsible for sending you the mail -- spammers can get
favourable SPF and CSV results too; that's why you need the database.

I was pointing out that, when all is said and done, SPF and CSV are
fairly much equivalent in what they achieve. It doesn't matter that, as
Stuart points out, they are different namespaces. That doesn't really
affect the _outcome_. You have an authenticated identity to look up in
your reputation database; that's it.

The point is that the host which is _actually_ sending you the mail can
quite happily munge the reverse-path to make it pass SPF -- that's what
SRS is about. But it doesn't have to be SRS -- anyone can do the same
trick just to make it pass SPF, even if they're just generating spam.

Given that any host can rewrite the reverse-path, all you can _really_
do is check how much you trust the individual host (or domain) which
takes responsibility for the mail which you're being offered. SPF is
only a hop-by-hop solution, and doesn't offer end-to-end authentication
_except_ obviously in the case where the transit _is_ only one hop.

So all that SPF really offers you is a way to authenticate the
individual host or domain which is sending you the mail. That's why I
say they're effectively equivalent -- that's all that CSV tries to do,
only CSV is doing it without trying to change the world.

And in answer to your third question -- of _course_ misdirected bounces
are a problem, and you know my solution. I don't see the relevance of
the question in this context though, since SPF and CSV don't even
attempt to address it. They will prevent bounce-spam in a tiny minority
of cases -- but that much would be achieved by _any_ mechanism which
would cause the mail to be rejected up-front instead of being accepted
and then bounced. SpamAssassin probably does more to prevent bounce-spam
than SPF and CSV do.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 2006-03-27 at 17:41 -0600, David Nicol wrote:
> Having just read the wikipedia page on CSV, I see that CSV relies on these
> phantom "reputable accreditation services" which seems to just push the question
> into more vague infrastructure.

No more so than SPF does; it's just a little more honest about it in the
documentation.

SPF prevents 'forgery' of the reverse-path.
CSV prevents forgery of the HELO name.

In the initial phase, you get to reject some mail which blatantly
doesn't match either SPF or CSV. (In the case of SPF you also end up
rejecting valid forwarded mail when you do that, but let's gloss over
that for the moment.)

You already see spammers with SPF passes -- and if either of SPF or CSV
were to become ubiquitous, then spammers would _all_ need SPF or CSV
success in order to get their mail through. Each of them stops being
useful on its own as soon as it starts to succeed

You _need_ the reputation database in that case. The point is that you
now _know_ they are who they claim to be, and you can safely use that as
a key in your reputation database.

It's just that CSV does it better, because it's simpler and it doesn't
have all the false rejections that SPF does.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Having just read the wikipedia page on CSV, I see that CSV relies on these
phantom "reputable accreditation services" which seems to just push the question
into more vague infrastructure.

SPF works. It does not achieve things that it was not designed to achieve,
but in the real world in which I live, in which I am the only
reputable accreditation
service that I trust, the only minor headache in switching to a SPF-aware
e-mail service has been that I needed to alter one of my mail forwarders to
do SRS. It doesn't do SRS-compliant SRS, but mail routed through that
forwarder is now rewritten, therefore I can receive mail to my @cpan.org address
even though it comes from the wrong server according to cpan.org's strict SPF
policy.

http://en.wikipedia.org/wiki/Certified_Server_Validation describes a scenario
with this caste of accreditaion services which is scary as it would
become a method
for top-down information control. Let's say that Emmanual Goldstein
(http://cronos.advenge.com/pc/Orwell/1984/p76.html) has his
credentials revoked...

SPF does not rely on someone else to vouch.

SPF could be made compatible with a vouching system. A vouching system could
be based on SPF-verifed identity. As one of the weaker of various options.
--
David L Nicol
There's nothing to it but to do it

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

after reading brian livingston's article, SPF and CSV don't seem to be
mutually exclusive.

IIRC, SPF has some validation of the HELO name described in it.

The adoption path would be harsher for CSV, as SRV records need to be installed
instead of just TXT records

and CSV lacks the optional fine-grained control that SPF provides,
unless there's
more to it.

Can't we all just get along?


On 3/27/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2006-03-27 at 17:41 -0600, David Nicol wrote:

> SPF prevents 'forgery' of the reverse-path.
> CSV prevents forgery of the HELO name.

> In the initial phase, you get to reject some mail which blatantly
> doesn't match either SPF or CSV. (In the case of SPF you also end up
> rejecting valid forwarded mail when you do that, but let's gloss over
> that for the moment.)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

>And in answer to your third question -- of _course_ misdirected bounces
>are a problem, and you know my solution.

Actually, we don't. Is it the same as Johann's laughable "solution";
the equivalent of running SpamAssassin?

> I don't see the relevance of
>the question in this context though, since SPF and CSV don't even
>attempt to address it.

The context is SRS (as it states in the subject) not really SPF or CSV.

>They will prevent bounce-spam in a tiny minority
>of cases

SRS does not prevent bounce-spam "in a tiny minority of cases", it
completely eliminates it. I am eliminating 80,000+ per day using SRS
signing and have not had a single spam report from a user since
implementation that involved a fake DSN.

SRS signing COMPLETELY eliminates fake-DSN spam, and without the
possibility of rejecting a real one. I am not saying "probably", I
am saying it DOES. I've been doing it for quite some time now.

SpamAssassin (or any heuristics, as Johann suggested) running on fake
DSNs won't catch any more than it does on any other mail (less than
80% here now) and will be subject to false positives, which would
REJECT a REAL DSN, which is a FAR worse problem. The repercussions
of rejecting a real DSN are much worse than accepting some fake-DSN spam.

>-- but that much would be achieved by _any_ mechanism which
>would cause the mail to be rejected up-front instead of being accepted
>and then bounced. SpamAssassin probably does more to prevent bounce-spam
>than SPF and CSV do.

More than SPF and CSV, yes. Not more than SRS. SRS has a perfect
record for fake-DSN spam on my server, after a couple YEARS of
running in excess of 1.5 million messages per day, I have had zero
complaints of lost real DSNs and zero complaints of fake-DSN spam.


--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> You already see spammers with SPF passes -- and if either of SPF or CSV
> were to become ubiquitous, then spammers would _all_ need SPF or CSV
> success in order to get their mail through. Each of them stops being
> useful on its own as soon as it starts to succeed

SPF/CSV don't stop "being useful on their own" as soon as they start to
succeed, just like CFC sprays don't stop being harmful to the environment
just because no one uses them anymore.

When SPF or CSV become ubiquitous, of course protected domains will by
definition no longer have an advantage over non-protected domains, but
SPF/CSV will still provide _security_ against potential harm. As soon as
they went away, forgery would return. Perhaps your definition of "useful"
does not include that security, but mine certainly does.

> You _need_ the reputation database in that case. The point is that you
> now _know_ they are who they claim to be, and you can safely use that as
> a key in your reputation database.

True.

> It's just that CSV does it better, because it's simpler and it doesn't
> have all the false rejections that SPF does.

It's true that CSV is simpler than SPF. However the "false rejections"
depend on what you consider "false". Alias-style forwarding (that
excludes former alias-style forwarders who now use sender rewriting) isn't
such a widely-used practice as many think it to be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKK4mwL7PKlBZWjsRAgjqAKDajCFlAUXWb15655rxO2iU6MRL5gCfY690
DYCqzEeErdnAv1QCB7pE7UQ=
=uud/
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

>>And in answer to your third question -- of _course_ misdirected bounces
>>are a problem, and you know my solution.

>Actually, we don't. Is it the same as Johann's laughable "solution";
>the equivalent of running SpamAssassin?

Hey never said that this is the final solution :-)
I said it is one possibility to do so ....
I never had a need to use Spamassaissin or bayes or similair content based
crap
[OFFTOPIC ON]
We are doing Spamdefense all on envelopes and some more advanced things on
tcp protocoll level and thats very efffective.
This all is done under control of a very flexible policy, where the clue is
that you can
have rules that are absolute and rules that depend on other rules....

Only for Information you can combine rules as:
Per default reject mail from Systems detected to be Dialups.
If a external System which is detected to be a Dialup is responsible MX for
claimed
sender domain, make an exception and accept that.

The power comes from setting rules lumping them together to have a great
policy.

[OFFTOPIC OFF]

But back to the thread:

There are much easier ways to reject faked bounces at SMTP-Envelope,
and you do not need to implement SRS to be also effective ...

Example:

Your emailadresses are in form of: user@example.tld
Just establish a subdomain exclusive for real bounces and set IP to your MX.
Set your MTA that all outgoing messages get a envelope-from like:
user@secretsubdomain.example.tld while the from address in the mail stays
untouched .

This way you can reject every bounce coming to user@example.tld, becuse you
know its a fake.

You see you really dont need SRS for this.
It is also very unlike that Spammers find out what your secret subdomain is
...

--

Johann Steigenberger
Blacklistmaster at UCEPROTECT-Network
http://www.uceprotect.net




-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

>It is also very unlike that Spammers find out what your secret subdomain is
>...

s/very unlike/extremely likely/

Spammers, and hosts that sell email lists to spammers, code their
MTAs to generate lists from incoming MAIL FROM: addresses, among other things.

Encoding something in the domain part is pretty stupid, anyway. Many
filtering/delivery rules are written based on domain. Suddenly, all
those rules out there become invalid because I've changed the domain
part of my outgoing mails. When my clients send out mail, it goes
all willy-nilly inexplicably, and I wind up having to explain my
goofy setup, and having people make special exceptions for me in
_their_ implementations, which probably won't often happen.

The local part is the right place to encode something to check when
it comes back.

Suppose I change my SRS implementation so that my tags are
different. Say, tx3*=*.*=*@tx3.net (instead of
srs*=*.*=*@tx3.net). Then your policy wouldn't apply to me. Now
suppose everyone using SRS did this. What do you do then? Violate
another RFC 2822 by rejecting all mail containing "="? Then I could
just change the SRS separator... :P



--
-- =========================
Tom Lahti
Tx3 Online Services

(888)4-TX3-SVC (489-3782)
http://www.tx3.net/
-- =========================

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 27 Mar 2006, Tom Lahti wrote:

> SRS does not prevent bounce-spam "in a tiny minority of cases", it
> completely eliminates it. I am eliminating 80,000+ per day using SRS
> signing and have not had a single spam report from a user since
> implementation that involved a fake DSN.
>
> SRS signing COMPLETELY eliminates fake-DSN spam, and without the
> possibility of rejecting a real one. I am not saying "probably", I
> am saying it DOES. I've been doing it for quite some time now.

Same here, with one caveat. Some braindead MTAs have a policy of
rejecting localparts from any domain containing '+' (same idea as rejecting
localparts beginning with SRS). Of course, this breaks many things
apart from SRS. For these domains, I have to turn off SRS signing.
As a consequence, I cannot accept DSNs from such braindead domains
(since they also relay bounce spam). Something for Johann to keep
in mind - and a caution against apply a "no SRS" policy to any
except a few braindead domains acting as an open relay.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Tue, 28 Mar 2006, Julian Mehnle wrote:

> It's true that CSV is simpler than SPF. However the "false rejections"
> depend on what you consider "false". Alias-style forwarding (that
> excludes former alias-style forwarders who now use sender rewriting) isn't
> such a widely-used practice as many think it to be.

Not aimed at Julian - but adding to what he said:

There are no false rejections of alias-style forwarding by SPF
when properly configured. As part of configuring an SPF implementation,
a receiver must ensure that

a) he does not check SPF from his alias-style forwarders

or

b) his forwarders use SRS

I recommend a. It is also important that the forwarders check SPF,
or there is no point in the receiver doing so.
I recommend a because the same logic must be applied in any case to any
secondary MX servers. Alias forwarders essentially act as
additional MX servers for your mailbox. A big "stupid SPF trick"
is to reject mail coming in through your secondary MX for SPF fail
(I've seen it happen on several big ISPs while serving on spf-help.)

Another "stupid SPF trick" is to so SRS forwarding without checking
SPF. This is stupid because:
a) if your forwarding targets don't check SPF, they don't need SRS
b) if they do check SPF, then you just made their efforts useless.

When talking about these "false rejections", you need to distinguish
between "user errors" and "method errors" (to borrow language from
the birth control industry). It is a valid criticism to claim that
a method is hard to use, and hence has a high user error rate - however
low the method error rate might be. BUT - please stop pretending
that user errors are method errors.

The number of false rejections of receiver configured alias-style
forwarding due to SPF method errors is ZERO. I admit that the
user error rate is frustratingly high.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 2006-03-27 at 18:24 -0800, Tom Lahti wrote:
> >And in answer to your third question -- of _course_ misdirected bounces
> >are a problem, and you know my solution.
>
> Actually, we don't. Is it the same as Johann's laughable "solution";
> the equivalent of running SpamAssassin?

http://www.infradead.org/rpr.html

Essentially the same principle as BATV, the original 'SES' before it
went off into the weeds, or self-signed SRS.

Basically I sign the reverse-path on any genuine outgoing mail so it
looks like an SRS address. Then I never accept bounces to the 'raw'
address 'dwmw2@infradead.org'. So anyone doing sender verification
callouts gets to reject faked mail, but _certainly_ I don't get bounces.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> On Mon, 2006-03-27 at 18:24 -0800, Tom Lahti wrote:
> > >And in answer to your third question -- of _course_ misdirected
> > > bounces are a problem, and you know my solution.
> >
> > Actually, we don't. Is it the same as Johann's laughable "solution";
> > the equivalent of running SpamAssassin?
>
> http://www.infradead.org/rpr.html
>
> Essentially the same principle as BATV, the original 'SES' before it
> went off into the weeds, or self-signed SRS.
>
> Basically I sign the reverse-path on any genuine outgoing mail so it
> looks like an SRS address. Then I never accept bounces to the 'raw'
> address 'dwmw2@infradead.org'. So anyone doing sender verification
> callouts gets to reject faked mail, but _certainly_ I don't get bounces.

As far as I could see from reviewing your webpage, your solution suffers
from the replay problem (apart from a weak datestamp verification). Did I
overlook anything?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKX/TwL7PKlBZWjsRAouyAKDEt5/ZYJMMRPzM6RvL/XjgHJ3uOgCg/iX1
4N3kjAnpSLWJGHGxT7EXlQQ=
=2oWC
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Jeftovic wrote:
> I guess the "Why SRS really sucks" thread reminded me that its time for
> me to poke my head up once again and ask what the current state of SRS
> is for an MTA like postfix 2.x
>
> So far there are only untested patches and nothing that can be used in a
> high volume production environment.

I'm no expert on SRS deployment, but I assume you have tried the
libsrs2-based patch[1]?

Oh, BTW, I note that libsrs.org is now dead (AKA domain-grabbed). :-(

References:
1. http://www.libsrs2.org/download.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEKYTiwL7PKlBZWjsRAmU3AJoCqSzmgbuvZl6nEQGYf9EpFN5F/QCfWeVc
JlULBpzWagZnKUDTY5mAtIY=
=eLCN
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Hi Julian, I don't think I've tried that yet. I'll take a look at it in
my copious spare time [tm] (my wife and I have just adopted a baby girl,
3 weeks old, so we're in a manic state around here)

-mark


Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Jeftovic wrote:
>
>>I guess the "Why SRS really sucks" thread reminded me that its time for
>>me to poke my head up once again and ask what the current state of SRS
>>is for an MTA like postfix 2.x
>>
>>So far there are only untested patches and nothing that can be used in a
>>high volume production environment.
>
>
> I'm no expert on SRS deployment, but I assume you have tried the
> libsrs2-based patch[1]?
>
> Oh, BTW, I note that libsrs.org is now dead (AKA domain-grabbed). :-(
>
> References:
> 1. http://www.libsrs2.org/download.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFEKYTiwL7PKlBZWjsRAmU3AJoCqSzmgbuvZl6nEQGYf9EpFN5F/QCfWeVc
> JlULBpzWagZnKUDTY5mAtIY=
> =eLCN
> -----END PGP SIGNATURE-----
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Tue, 2006-03-28 at 18:26 +0000, Julian Mehnle wrote:
> As far as I could see from reviewing your webpage, your solution suffers
> from the replay problem (apart from a weak datestamp verification). Did I
> overlook anything?

Yes. You missed the fact that it doesn't matter. It's not designed for
authentication -- it's designed to protect me from the flood of bounce
spam, and it's done that perfectly effectively. It allows me to identify
some mail as being _definitely_ fake, and thus allows me to reject that
mail.

As an added side-effect, it gives third parties a way to reject faked
mail too -- but that's just a coincidence. People who bother to do
sender verification callouts just get that benefit automatically.

SPF offers 'yes' and 'maybe' answers to the question of whether a sender
address is genuine. For reasons which have been discussed at length
already, it can't offer a 'no' answer with 100% reliability.

In contrast, BATV &c offer 'no' and 'maybe' answers, and it's the 'yes'
answer which it can't give with 100% reliability -- as you've observed,
there's a slight possibility of a replay attack.

SES attempted to make the whole thing more complex to deal with that,
and in my opinion that added complexity was pointless. It just doesn't
matter -- the crap which SES added to turn the final remaining 'maybe'
answers into 'yes' answers was just not worth it. IMO.

The point is that I want to be able to _reject_ unwanted incoming mail.
And for that, the 'yes' and 'maybe' answers aren't helpful. It's only
the 'no' answer which is useful to me.

This is because because a reliable 'no, this is crap' answer means I can
certainly reject it safely, while the 100% 'yes, this is authentic' is
only really useful in conjunction with a reputation database.

--
dwmw2

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com