sethg at GoodmanAssociates
Feb 22, 2004, 2:38 PM
Post #10 of 24
(4530 views)
Permalink
|
> [Mark]
> Perhaps you are looking at this from the wrong angle? An SRS
> address is --
> or rather, should never be, considered a pass-key. Instead of
> using positive
> logic, we should use negative logic: "Not every bounce whose
> envelope-from
> passes the SRS 'reverse' test, is valid per se for that
> reason. But should
> that same envelope-from fail the test, or is not SRS signed
> at all, then it
> may be invalid."
>
> An empty envelope-from + unsigned SRS address + DATA phase,
> these three
> conditions together are eough to make a negative
> determination: the bounce
> is fake -- assuming, of course, you sign your outgoing envelope-from
> addresses. That is negative logic: not the presence of a
> valid SRS signed
> address determines our course, but the absence of an
> (expected) SRS address
> + two supporting conditions. I outlined most of this in my sendmail
> integration project:
>
> http://asarian-host.net/srs/sendmailsrs.htm
>
> If you are going into this, with the idea of a single SRS
> address, in and by
> itself, providing a positive, water-proof authentication,
> then I fear you wi
> ll be disappointed.
As SRS stands now, I am disappointed. By making these various
suggestions, all I'm asking is: is there a way to avoid having an
SRS-signed address give a spammer a clear channel into my mailer? I
understand that I can and will always further scrutinize every message,
even if it passes SPF and SRS. However, an explicit SRS-pass is a
positive value in any weighting scheme, and that makes spam harder to
detect. To make matters worse, legitimate DSN's are among the most
important messages, which leads one to be more lenient in scoring
apparent bounces (assuming that we put enough logic in the mailer to do
that). Perhaps I will be disappointed, but I would like to find out if
we can do something with SRS to avoid encouraging bounce spam.
>
> > 1) When an MTA receives a bounce, validate the SRS0 hash.
> >
> > 2) If the hash verifies, check the local bounce cache for the
> > hash_value/timestamp. If it exists in the local cache,
> reject the bounce.
> >
> > 3) If the hash_value/timestamp does not exist in the local
> cache, enter it
> > in the cache and accept the bounce.
>
> You lost me here. If I sign A address, to form SRS address B,
> then if I sign
> A again, the new address C will be the same as address B (for
> a while). So,
> are you saying, that if I send out 5 messages in a row, that
> I can only
> receive one bounce for the lot? Surely not, I hope.
You are absolutely right. With the timestamp set to one day resolution,
that invalidates this bounce cache approach. I personally think it
unnecessarily miserly in character count to do that. I would recommend
that the timestamp have at least 1 millisecond resolution, so that it
can support a couple of million messages per hour with unique
timestamps. Looking to the future, with faster hardware and more
network bandwidth, we should probably consider 100microsecond
resolution.
With 14-bits to the right of the binary point, we have 61 microsecond
resolution or 59 million unique timestamps per hour. With the present
12-bit day field, that gives a total of 26-bits, or six base-32
characters. If we reduce the number of bits in the day field from 12 to
11, it would be 25-bits total, or five base-32 characters. This
increases the timestamp from two characters to five, but there is an
immediate bounce-spam prevention payback. There now, I'll surely be
flamed, but like they say, if 'ya can't take the heat, get out of the
kitchen.
If we change the secret at least every five years (that's pretty
reasonable, isn't it?), we are then covered for when the timestamp wraps
around every 5.6 years. Every single message we ever send will have a
unique timestamp. Since I was suggesting storing the timestamp with the
hash value in the bounce cache, a hash collision is not even a
consideration. In fact, if we increase the timestamp resolution as I
have suggested, all we have to store is the timestamp itself since that
uniquely identifies an outgoing message. This is starting to sound
interesting.
As an aside, and risking a total list flameout, let me suggest that we
entertain using six base-32 characters for the timestamp: 16-bits for
the day field and 14-bits for the fractional day field. That gives us
61 microsecond resolution over a period of 179 years. The eleven year
rollover is now history and the timestamp becomes a unique message ID
right in the return-path. Really, a six character timestamp field is
small compared to the address information so what's the real issue here?
Certainly not network bandwidth, considering the bloated HTML emails
flying around. Being a hardware guy (quick, get the clue bat!), I can
tell you that you can't even send an Ethernet packet shorter than about
64 bytes, so let's keep things in perspective. A packet could
theoretically get shortened at a network bridge further down the line,
but even ATM packets have fixed 53 byte payloads, so let's get real.
Segmentation and reassembly across network bridges is not trivial, but
in general, very short packets get padded and stay that way for ease of
implementation. Unless you are using a dialup modem, your short telnet
strings are being padded out to 64 bytes before they leave your machine
and stripped at the destination.
Getting back to the local bounce-cache idea, even with a unique
timestamp on each message, that still leaves Brian's objection, which I
also posted as a possibility earlier. That is, if a forged bounce beats
a legitimate back to the MTA for a given outgoing message, it would
effectively block the legitimate bounce. If this can really happen,
Brian is right and the method is kaput. However, I think (hope) it
can't happen for the following reason (again, help me out if I'm
misunderstanding something): until the message is delivered to the end
target, there is no way for a spammer to harvest the SRS-signed return
path from it. If it is successfully delivered and a spammer harvests
the return-path, there will be no DSN. If it bounces anywhere along the
delivery path, there is nothing for the spammer to harvest so the real
DSN will be the only one coming back. Does this analysis hold water?
--
Seth Goodman
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss [at] v2
|
