Mailing List Archive

On Thu, 2004-03-04 at 00:13 +0000, spf@anarres.org wrote:
> A new version of the SRS documentation to accompany version 0.29 of the
> software has been released on the SRS distribution page at
> http://www.anarres.org/projects/srs/

§1.2. It affects any mail server which will obey .forward files or the
equivalent. It could be misleading to state that it does not include
company-internal smarthosts; some such hosts may well forward mail.

Also, many naïve readers may think that 'simple send/receive-only mail
servers' describes their server on which a user may be using .forward
files.

You should avoid using the phrase 'public forwarding' since it's
misleading. All hosts capable of doing forwarding are in the same boat;
that is basically most mail installations in existence.

§2.9. s/spamemr/spammer/ in final paragraph.

--
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 Thu, 2004-03-04 at 00:13 +0000, spf@anarres.org wrote:
> A new version of the SRS documentation to accompany version 0.29 of the
> software has been released on the SRS distribution page at
> http://www.anarres.org/projects/srs/
> It is available in DVI, PostScript and PDF formats.

§2.8 is ambiguous about the hash used. I assume you mean to add a _new_
hash at each stage, not quote the original one added by the first host
which rewrites SRS0 to SRS1?

So it should presumably read...

Hop Address Return path
1 user@source.com user@source.com
2 alias@forward.com SRS0=HHH0=TT=source.com=user@forward.com
3 target@bouncer.com SRS1=HHH1=forward.com==HHH0=TT=source.com=user@bouncer.com
4 relay.com SRS1=HHH2=forward.com==HHH0=TT=source.com=user@relay.com

<Message bounces>

SRS1=HHHn=forward.com==HHH0=TT=source.com=user@somewhere.com
SRS0=HHH0=TT=source.com=user@forward.com
user@source.com

Now, you say "Of course there is nothing to prevent the bouncing mailer
daemon from being SRS1-aware and [implementing?] step n+1, as long as it
does not skip the SRS0 step by removing B (in this case, forward.com)."

1. How does the bouncing mailer check the hash HHHn which was added by
the previous step?

2. What prevents an attacker _pretending_ to be bouncer.com in stage 3
above, and sending a mail from 'SRS1+HHHx+forward.com==...@bouncer.com'
in the knowledge that 'bouncer.com' and the bogus hash HHHx will be
removed from the address entirely, leaving a successful joe-job of an
SRS0 address at forward.com (which admittedly is unlikely to be accepted
and probably isn't too much of a problem)?

This does seem to fix the problem of mail getting _directly_ through the
hosts which rewrite SRS1->SRS0, because each one will check for its own
hash. Only joe-jobs are possible with this, and that's not too much of a
problem.

You need to include a study of the resultant length of your localparts
in the 'Guarded Scheme' and estimate the possibility that they will
exceed the 64-character limit.

You also need to consider the amount of local storage required per
address in the 'Database Scheme'. Perhaps consider a hybrid scheme where
addresses which _will_ fit into 64 characters are encoded using the
Guarded Scheme, but those which would break are put in the database
instead?

Also consider the possibility of attacks designed specifically to use up
local storage at a forwarding host.

> It's my job to produce protocols, it's your job to produce attacks on
> the protocol.

Not really. It's my job just to observe that I'm not sufficiently
convinced, and I don't want to roll out such a fundamental change to the
way my systems have operated for years, just to make the flawed
assumptions made by SPF come true and hence render it a viable concept.

So I disagree slightly with your statement above that it's only up to
you to document the protocol, and for others to challenge it. Your task
-- maybe not yours _personally_, Shevek, but the advocates of SPF -- is
to make whatever scheme you propose is so _obviously_ safe and correct
that the world will implement it without having to think twice.

Because if you can't do that then it's never going to happen.

--
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 Thu, 4 Mar 2004, David Woodhouse wrote:

> On Thu, 2004-03-04 at 00:13 +0000, spf@anarres.org wrote:
> > A new version of the SRS documentation to accompany version 0.29 of the
> > software has been released on the SRS distribution page at
> > http://www.anarres.org/projects/srs/
>
> §1.2. It affects any mail server which will obey .forward files or the
> equivalent. It could be misleading to state that it does not include
> company-internal smarthosts; some such hosts may well forward mail.

That note means that company smarthosts will be included in the SPF record
for that company and thus will not need to perform SRS. In fact, the
Mail::SRS code will perform a noop under many such circumstances. I will
correct the note and the description.

> Also, many naïve readers may think that 'simple send/receive-only mail
> servers' describes their server on which a user may be using .forward
> files.
>
> You should avoid using the phrase 'public forwarding' since it's
> misleading. All hosts capable of doing forwarding are in the same boat;
> that is basically most mail installations in existence.

The 'public forwarder' is intended to mean a host on which an arbitrary
spammer may construct a forwarding address, which may be restricted to
mail to some account to which the spammer has access.

> §2.9. s/spamemr/spammer/ in final paragraph.

Thankyou.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
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 Thu, 4 Mar 2004, David Woodhouse wrote:

> On Thu, 2004-03-04 at 00:13 +0000, spf@anarres.org wrote:
> > A new version of the SRS documentation to accompany version 0.29 of the
> > software has been released on the SRS distribution page at
> > http://www.anarres.org/projects/srs/
> > It is available in DVI, PostScript and PDF formats.
>
> §2.8 is ambiguous about the hash used. I assume you mean to add a _new_
> hash at each stage, not quote the original one added by the first host
> which rewrites SRS0 to SRS1?
>
> So it should presumably read...
>
> Hop Address Return path
> 1 user@source.com user@source.com
> 2 alias@forward.com SRS0=HHH0=TT=source.com=user@forward.com
> 3 target@bouncer.com SRS1=HHH1=forward.com==HHH0=TT=source.com=user@bouncer.com
> 4 relay.com SRS1=HHH2=forward.com==HHH0=TT=source.com=user@relay.com
>
> <Message bounces>
>
> SRS1=HHHn=forward.com==HHH0=TT=source.com=user@somewhere.com
> SRS0=HHH0=TT=source.com=user@forward.com
> user@source.com

Ah, yes, this is kind of a side-effect of the fact that I used a lazy
LaTeX macro to produce those addresses. I have hopefully clarified this in
the argument.

> Now, you say "Of course there is nothing to prevent the bouncing mailer
> daemon from being SRS1-aware and [implementing?] step n+1, as long as it
> does not skip the SRS0 step by removing B (in this case, forward.com)."
>
> 1. How does the bouncing mailer check the hash HHHn which was added by
> the previous step?

It doesn't. In fact, in the light of recent discussions, I will remove
this paragraph, since this might lead to an SRS-aware mailer spamming SRS0
at some host (irrelevant, but some people don't like it).

> 2. What prevents an attacker _pretending_ to be bouncer.com in stage 3
> above, and sending a mail from 'SRS1+HHHx+forward.com==...@bouncer.com'
> in the knowledge that 'bouncer.com' and the bogus hash HHHx will be
> removed from the address entirely, leaving a successful joe-job of an
> SRS0 address at forward.com (which admittedly is unlikely to be accepted
> and probably isn't too much of a problem)?

Not a lot, but this requires quite a convoluted set of circumstances
involving multiple forwarders, all of which must be set up by the victim,
not by the spammer.

> This does seem to fix the problem of mail getting _directly_ through the
> hosts which rewrite SRS1->SRS0, because each one will check for its own
> hash. Only joe-jobs are possible with this, and that's not too much of a
> problem.
>
> You need to include a study of the resultant length of your localparts
> in the 'Guarded Scheme' and estimate the possibility that they will
> exceed the 64-character limit.

There is a brief such study in the subsection entitled "the 64 character
limit" but I have not included Meng's data. Perhaps I should.

> You also need to consider the amount of local storage required per
> address in the 'Database Scheme'. Perhaps consider a hybrid scheme where
> addresses which _will_ fit into 64 characters are encoded using the
> Guarded Scheme, but those which would break are put in the database
> instead?
>
> Also consider the possibility of attacks designed specifically to use up
> local storage at a forwarding host.

I will consider this as well. I have put blank headings into the document,
upon which I will expand as soon as I have time.

> > It's my job to produce protocols, it's your job to produce attacks on
> > the protocol.
>
> Not really. It's my job just to observe that I'm not sufficiently
> convinced, and I don't want to roll out such a fundamental change to the
> way my systems have operated for years, just to make the flawed
> assumptions made by SPF come true and hence render it a viable concept.
>
> So I disagree slightly with your statement above that it's only up to
> you to document the protocol, and for others to challenge it. Your task
> -- maybe not yours _personally_, Shevek, but the advocates of SPF -- is
> to make whatever scheme you propose is so _obviously_ safe and correct
> that the world will implement it without having to think twice.
>
> Because if you can't do that then it's never going to happen.

With mild amusement: I challenge you to apply the same argument to SHA1
itself, or RSA, or DSA, or ssh, or Microsoft Windows, or Cisco IOS, or any
other technology which you use from day to day!

Actually, I agree with you and I should be making it as clear as possible;
these comments above are EXTREMELY valuable to me in making this so.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
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 Fri, 2004-03-05 at 10:49 +0000, spf@anarres.org wrote:
> With mild amusement: I challenge you to apply the same argument to SHA1
> itself, or RSA, or DSA, or ssh, or Microsoft Windows, or Cisco IOS, or any
> other technology which you use from day to day!

I cannot. Because the deployment of those technologies does not
represent a massive departure from the status quo, rendering
interoperation impossible.

When SSH became popular, it was rolled out gradually and didn't break
existing users of telnet.

If SSH were to run on port 23 instead of port 22, and hence _break_
existing users of telnet, the analogy would be a little better. And SSH
wouldn't have caught on anywhere near as quickly as it did.

Linux replacing Windows, or IPv6 replacing IPv4, would be better
analogies.

> Actually, I agree with you and I should be making it as clear as possible;
> these comments above are EXTREMELY valuable to me in making this so.

HTH. Just because I think you're on crack doesn't mean I wish it could
work :)

--
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 Fri, 2004-03-05 at 11:50 +0000, David Woodhouse wrote:
> ... doesn't mean I wish it could work :)

er...

s/wish/don't wish/

Coffee first. Then email.

--
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

Here are several minor comments on the documentation dated March 5,
2004.


1) Section 1.2: Though you _do_ specifically start out saying that
servers that use .forward files must use SRS, I still think that the
list of who this does _not_ affect is a bit misleading. In particular,
company smart hosts frequently support forwarding. Unless they
specifically disable this, SRS applies to them. Similarly, even the
simple send/receive-only servers you mention frequently set up
forwarding accounts for others. I'd wager that ones who don't allow
forwarding are the exception rather than the rule. Even if they don't
currently use it, if it is not disabled, when they add a forward they
will not likely recall the caveat about SRS and forwarding. My
suggestion is to replace the third and fourth lines of the "this does
not include" list with something like:

* mail servers that explicitly disable forwarding


2) Section 2.3: The example of the SRS0 format in the seventh line uses
"+" separators from the original SRS0 format. These should probably be
converted to "=" for consistency and since the "+" is only allowed as
the initial separator, if I understand the formal specification
correctly. The last paragraph in this section also mentions the "+"
separator in several places.


3) Section 2.7: The second to last sentence starting with, "However,
some parts of the community were concerned about ..." suggests that the
reason the second hash was added to SRS1 addresses was merely to prevent
an ineffective DOS vulnerability. In fact, the reason this is now here
is to close the limited open relay we had inadvertently created. Even
though it would not be particularly abusable, it could easily land the
machine's IP on an open relay blacklist. I suggest replacing the
sentence I referenced above with something like:

The hash in the SRS1 address is present to prevent the machine that
first creates an SRS1 return-path from becoming a limited open relay.
While the particular open relay created would be of limited use to
spammers, it could cause the machine to be listed as an open relay.


4) Section 2.9: Line 5 says, "He then mails himself via D.". Perhaps I
misunderstand the attack, but I think it should be "via B" instead of D.


5) Section 4.2: The third sentence starts out, "Only the first few
characters of the hash are used: Since ...". I couldn't find anywhere
in the document where the exact number of base64 characters is
specified, though I suspect it is three from the usage "HHH". Also, the
word "since" should not be capitalized.


6) Section 4.4: The second sentence, "SRS introduces at most 33
characters plus two hostnames plus the original local part as overhead
into the local-part.", is a bit confusing. The original local part is
already in current return-paths and you are trying to describe what is
added. I know what you mean here, but it could be clearer.

--

Seth Goodman

-------
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 Fri, 5 Mar 2004, Seth Goodman wrote:

> Here are several minor comments on the documentation dated March 5,
> 2004.
>
> 1) Section 1.2: Though you _do_ specifically start out saying that
> servers that use .forward files must use SRS, I still think that the
> list of who this does _not_ affect is a bit misleading. In particular,
> company smart hosts frequently support forwarding. Unless they

But are not required to support SRS if they are designated in the SPF
record for that company. Since this will be the case, they are not
required to support SRS. I have made this even more explicit.

> specifically disable this, SRS applies to them. Similarly, even the
> simple send/receive-only servers you mention frequently set up
> forwarding accounts for others. I'd wager that ones who don't allow

If it's a simple send/receive only, then by definition it is not
forwarding.

> forwarding are the exception rather than the rule. Even if they don't
> currently use it, if it is not disabled, when they add a forward they
> will not likely recall the caveat about SRS and forwarding. My
> suggestion is to replace the third and fourth lines of the "this does
> not include" list with something like:
>
> * mail servers that explicitly disable forwarding

I have made this more explicit.

> 2) Section 2.3: The example of the SRS0 format in the seventh line uses
> "+" separators from the original SRS0 format. These should probably be

Whoops. I didn't use my \srs{} macro for that instance. I have fixed it.

> converted to "=" for consistency and since the "+" is only allowed as
> the initial separator, if I understand the formal specification
> correctly. The last paragraph in this section also mentions the "+"
> separator in several places.
>
>
> 3) Section 2.7: The second to last sentence starting with, "However,
> some parts of the community were concerned about ..." suggests that the
> reason the second hash was added to SRS1 addresses was merely to prevent
> an ineffective DOS vulnerability. In fact, the reason this is now here
> is to close the limited open relay we had inadvertently created. Even
> though it would not be particularly abusable, it could easily land the
> machine's IP on an open relay blacklist. I suggest replacing the
> sentence I referenced above with something like:
>
> The hash in the SRS1 address is present to prevent the machine that
> first creates an SRS1 return-path from becoming a limited open relay.
> While the particular open relay created would be of limited use to
> spammers, it could cause the machine to be listed as an open relay.

I have rephrased this paragraph. It isn't critical.

> 4) Section 2.9: Line 5 says, "He then mails himself via D.". Perhaps I
> misunderstand the attack, but I think it should be "via B" instead of D.

You misunderstand the attack. This is the 5 party game. If he could mail
himself via B then it would be a 3 party game.

> 5) Section 4.2: The third sentence starts out, "Only the first few
> characters of the hash are used: Since ...". I couldn't find anywhere
> in the document where the exact number of base64 characters is
> specified, though I suspect it is three from the usage "HHH". Also, the
> word "since" should not be capitalized.

The number of characters is specified as a configuration parameter of SRS.

The "Since" is capitalised because what follows the explanatory colon is a
sentence in its own right. I prefer the capitalisation here. A well known
reference on punctuation is "You Have a Point" by Eric Partridge, and he
allows either case after an explanatory colon if the following clause is a
full sentence. It's a matter of personal taste.

> 6) Section 4.4: The second sentence, "SRS introduces at most 33
> characters plus two hostnames plus the original local part as overhead
> into the local-part.", is a bit confusing. The original local part is
> already in current return-paths and you are trying to describe what is
> added. I know what you mean here, but it could be clearer.

Fixed, thanks. It probably isn't exactly 33 characters, even by default,
any more, but it's about that. I think it's at most 21. It doesn't really
matter, and if anyone else is actually bothered enough to count, I'll
correct it! :-)

I put in a list of systems which enforce the 64 byte limit. I'm sure we
had two, but I can only remember the PIX.

Thanks for the corrections. I have uploaded a new version with these
fixes. These comments are all very helpful, especially from the outside
viewpoint held by many on this list. I hope this revision satisfies your
comments.

I still have outstanding some detailed protocol examples (currently
wrapped in a comment environment, but on the way).

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

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

> -----Original Message-----
> From: owner-srs-discuss@v2.listbox.com
> [mailto:owner-srs-discuss@v2.listbox.com]On Behalf Of spf@anarres.org
> Sent: Friday, March 05, 2004 2:20 PM
> To: srs-discuss@v2.listbox.com
> Subject: RE: [srs-discuss] SRS documentation release
>
>
> On Fri, 5 Mar 2004, Seth Goodman wrote:
>
> > Here are several minor comments on the documentation dated March 5,
> > 2004.
> >
> > 1) Section 1.2: Though you _do_ specifically start out saying that
> > servers that use .forward files must use SRS, I still
> > think that the
> > list of who this does _not_ affect is a bit misleading. In
> > particular,
> > company smart hosts frequently support forwarding. Unless they
>
> But are not required to support SRS if they are designated in the SPF
> record for that company. Since this will be the case, they are not
> required to support SRS. I have made this even more explicit.

For the case of outgoing mail originating from their site, that is
certainly true. I was thinking of a company forwarding received mail
(using the same mailer). For example, an employee transfers from
companyX to one of their subsidiaries, companyZ, which still operates
their own mail system. The employee's old mailbox,
someone@companyX.com, is now set to forward to someone@companyZ.com. In
this case, I think companyX needs to implement SRS since the incoming
mail they forward could already have an SRS0-style or SRS1-style
return-path. If they don't rewrite the return-path and companyZ does
SPF checks, the SPF result should be fail.


>
> > 2) Section 2.3: The example of the SRS0 format in the
> > seventh line uses
> > "+" separators from the original SRS0 format. These should
> > probably be
>
> Whoops. I didn't use my \srs{} macro for that instance. I
> have fixed it.
>
> > converted to "=" for consistency and since the "+" is only
> > allowed as
> > the initial separator, if I understand the formal specification
> > correctly. The last paragraph in this section also mentions the "+"
> > separator in several places.

You fixed the SRS0 address but the "+" separators still remain in the
last paragraph. Also, the sentence in the local-part definition says,
"The order of the hostname and local-part was chosen to allow the use of
the + character as a separator". The local-part can have "+" inside it
and that was the original motivation for the field ordering, but I'm not
sure this statement is true anymore. It doesn't really hurt anything,
I'm just nit-picking.


> > 4) Section 2.9: Line 5 says, "He then mails himself via
> > D.". Perhaps I
> > misunderstand the attack, but I think it should be "via B"
> > instead of D.
>
> You misunderstand the attack. This is the 5 party game. If he
> could mail
> himself via B then it would be a 3 party game.

I'm not surprised. I've always found the 5-party attack confusing and
could use some help understanding it. Where does the forwarding account
that the spammer has on D forward to? It says that it points "to
himself", but at which domain? Since the next sentence says, "Now he
has an SRS1 return path which routes via D to B, and he can send mail to
a username starting SRS0 at B.", I am obviously missing something.


>
> > 5) Section 4.2: The third sentence starts out, "Only the first few
> > characters of the hash are used: Since ...". I couldn't
> > find anywhere
> > in the document where the exact number of base64 characters is
> > specified, though I suspect it is three from the usage
> > "HHH". Also, the
> > word "since" should not be capitalized.
>
> The number of characters is specified as a configuration
> parameter of SRS.

Fair enough, but do you have a recommendation? We recommend, but don't
require SHA-1 as a hash algorithm yet strongly warn implementers about
changing that. Similarly, we should probably recommend whatever you
consider to be a reasonable number of hash digits for similar reasons.
If your implementation has a default, you've obviously thought through
the issue, so you would be doing other implementers a favor by putting
it in the document as recommended but not required.

--

Seth Goodman

-------
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 Fri, Mar 05, 2004 at 08:19:33PM +0000, spf@anarres.org wrote:
> On Fri, 5 Mar 2004, Seth Goodman wrote:
>
> > Here are several minor comments on the documentation dated March 5,
> > 2004.
> >
> > 1) Section 1.2: Though you _do_ specifically start out saying that
> > servers that use .forward files must use SRS, I still think that the
> > list of who this does _not_ affect is a bit misleading. In particular,
> > company smart hosts frequently support forwarding. Unless they
>
> But are not required to support SRS if they are designated in the SPF
> record for that company. Since this will be the case, they are not
> required to support SRS. I have made this even more explicit.

Perhaps I do not understand the concept of a smarthost; I thought it
just means a relay. Why would an inbound mail relay be in the SPF
record for a domain?

Mate

--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

-------
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 Fri, Mar 05, 2004 at 04:57:23PM -0600, Seth Goodman wrote:
> For the case of outgoing mail originating from their site, that is
> certainly true. I was thinking of a company forwarding received mail
> (using the same mailer).

'inbound smarthost' in Google gives

http://www.floosietek.com/files/FTGateRelay_scenario.pdf

as the top entry.

Mate

-------
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 Fri, 5 Mar 2004, Seth Goodman wrote:

> > > 1) Section 1.2: Though you _do_ specifically start out saying that
> > > servers that use .forward files must use SRS, I still think that the
> > > list of who this does _not_ affect is a bit misleading. In
> > > particular, company smart hosts frequently support forwarding.
> > > Unless they
> >
> > But are not required to support SRS if they are designated in the SPF
> > record for that company. Since this will be the case, they are not
> > required to support SRS. I have made this even more explicit.
>
> For the case of outgoing mail originating from their site, that is
> certainly true. I was thinking of a company forwarding received mail
> (using the same mailer). For example, an employee transfers from
> companyX to one of their subsidiaries, companyZ, which still operates
> their own mail system. The employee's old mailbox,
> someone@companyX.com, is now set to forward to someone@companyZ.com. In
> this case, I think companyX needs to implement SRS since the incoming
> mail they forward could already have an SRS0-style or SRS1-style
> return-path. If they don't rewrite the return-path and companyZ does
> SPF checks, the SPF result should be fail.

This is correct, but such a server isn't playing the role of a smarthost
in that transaction. It's a forwarding server, and therefore covered. I
have made the description more explicit.

> > > 2) Section 2.3: The example of the SRS0 format in the seventh line
> > > uses "+" separators from the original SRS0 format. These should
> > > probably be
> >
> > Whoops. I didn't use my \srs{} macro for that instance. I have fixed
> > it.
>
> You fixed the SRS0 address but the "+" separators still remain in the
> last paragraph. Also, the sentence in the local-part definition says,
[SNIP]
> I'm just nit-picking.

No, it's valid, it was an oversight and I have fixed it.

> > > 4) Section 2.9: Line 5 says, "He then mails himself via D.".
> > > Perhaps I misunderstand the attack, but I think it should be "via B"
> > > instead of D.
> >
> > You misunderstand the attack. This is the 5 party game. If he could
> > mail himself via B then it would be a 3 party game.
>
> I'm not surprised. I've always found the 5-party attack confusing and
> could use some help understanding it. Where does the forwarding account
> that the spammer has on D forward to? It says that it points "to
> himself", but at which domain? Since the next sentence says, "Now he
> has an SRS1 return path which routes via D to B, and he can send mail to
> a username starting SRS0 at B.", I am obviously missing something.

D points to the spammer anywhere. It really doesn't matter. All the
spammer has to do here is to generate a properly signed SRS1 address
pointing to a spammer generated (and thus invalid) SRS0 address.

> > > 5) Section 4.2: The third sentence starts out, "Only the first few
> > > characters of the hash are used: Since ...". I couldn't find
> > > anywhere in the document where the exact number of base64 characters
> > > is specified, though I suspect it is three from the usage "HHH".
> > > Also, the word "since" should not be capitalized.
> >
> > The number of characters is specified as a configuration parameter of
> > SRS.
>
> Fair enough, but do you have a recommendation? We recommend, but don't
> require SHA-1 as a hash algorithm yet strongly warn implementers about
> changing that. Similarly, we should probably recommend whatever you
> consider to be a reasonable number of hash digits for similar reasons.
> If your implementation has a default, you've obviously thought through
> the issue, so you would be doing other implementers a favor by putting
> it in the document as recommended but not required.

The software defaults to 4, which gives 24 bits. I will add notes.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
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 Fri, 5 Mar 2004 mw-list-srs-discuss@csi.hu wrote:

> On Fri, Mar 05, 2004 at 08:19:33PM +0000, spf@anarres.org wrote:
> > On Fri, 5 Mar 2004, Seth Goodman wrote:
> >
> > > Here are several minor comments on the documentation dated March 5,
> > > 2004.
> > >
> > > 1) Section 1.2: Though you _do_ specifically start out saying that
> > > servers that use .forward files must use SRS, I still think that the
> > > list of who this does _not_ affect is a bit misleading. In particular,
> > > company smart hosts frequently support forwarding. Unless they
> >
> > But are not required to support SRS if they are designated in the SPF
> > record for that company. Since this will be the case, they are not
> > required to support SRS. I have made this even more explicit.
>
> Perhaps I do not understand the concept of a smarthost; I thought it
> just means a relay. Why would an inbound mail relay be in the SPF
> record for a domain?

I was thinking of the sendmail smarthost/mailhub/whatever feature. I have
made the description more explicit.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

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