Mailing List Archive

On Fri, Feb 06, 2004 at 12:27:35PM -0500, Meng Weng Wong wrote:
|
| We also need to draft a new SRS spec that has a clearly defined
| delimiter so that multple forwarding hops can perform reduction. Once
| we have a clearly defined delimiter and an indicator prefix, SRS and RPR
| and other schemes can play well together.
|

I believe the author of RPR is now on this list with us. Welcome!
To bring everybody up to speed here are some comments he sent in agreement:

This was in fact one of my concerns with SRS. Whilst there were a lot of
ideas and proposed concepts, the implementation did not seem to enforce
a single standardized format, so cutting the middleman cannot not
generally work.

I thought that what is needed is not immediately a better
implementation, but first of all a well designed scheme which defines
every aspect of return path rewriting, including exactly how the cookie
mechanism should work, which kinds of delimiters, and what kind of
escaping would be used (and the reference implementation should not
allow people to override these things, or at least should not encourage
people to do so). Otherwise, cutting the middleman cannot work
universally.

As for the local parts of the envelope sender, it would be interesting
to know about practical bounds -- what are the limits on the envelope
local parts in currently deployed MTA software? RFC 2821 guarantees a
minimum of 64 characters, but encourages implementors to impose no
length limits.

It should also be noted that cutting the middleman breaks the rules of
RFC2821, section 2.3.10: "[...] the local-part MUST be interpreted and
assigned semantics only by the host specified in the domain part of the
address." -- as there is no way to be sure that a given envelope sender
address really *is* rewritten according to the same scheme. So unless
there will be some widely accepted rewriting scheme, I am unsure whether
cutting the middleman is the right thing to do just yet.

I think we can get to a widely accepted rewriting scheme if we can agree
on a inter-hop delimiter and a first-word prefix indicator.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

----- Original Message -----
From: "Meng Weng Wong" <mengwong@dumbo.pobox.com>
To: <spf-devel@v2.listbox.com>
Sent: Friday, February 06, 2004 6:27 PM
Subject: [spf-devel] Moving ahead with SRS

> There are four MTAs out there. Each needs a patch or a plugin. We also
> need two libraries to base the patches on: one in C and one in Perl.
>
> Shevek is working on the Perl Mail::SRS. James has volunteered to
> translate it into C when he is done. We need volunteers to help with
> the rest: we need a test coordinator and we need someone to be
> responsible for each MTA. (James gets first dibs on qmail, Wayne gets
> first dibs on testing.)

You want SRS in the sendmail spf-milter too? I will gladly add it.

So far I stayed clear of it, because I think the Mail::SRS docs said
something to the effect of it being very, very, alpha, and not to touch it
with a ten-foot pool, etc. :) So, I figured to wait a bit before having a go
at it.

Just say they word. :)

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Fri, Feb 06, 2004 at 05:49:54PM +0000, Mark wrote:
|
| You want SRS in the sendmail spf-milter too? I will gladly add it.
|

Awesome, thanks Mark.

Yes, now that Shevek is applying some rigour to Mail::SRS I expect we
can start doing real work now. (He's a professional programmer with
proper training in crypto and formal systems and so on, unlike this
jack-of-all-trades over here.)

There is an argument for packaging SPF and SRS separately. There will
are sites that will want to do SRS without SPF.

There is an argument for packaging SPF and SRS together. There are
sites that want to do SRS only if the sending host has SPF.

I think packaging them together makes sense if we can toggle the
functionality separately.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

Hi, as previously stated in my "introductory" mail, I am the author of new
prototype versions of Mail::SRS, a Perl implementation of SRS. My notes
and thoughts from the time of writing that code may be found at
http://www.anarres.org/projects/srs/

And so to the thread...

> It should also be noted that cutting the middleman breaks the rules of
> RFC2821, section 2.3.10: "[...] the local-part MUST be interpreted and
> assigned semantics only by the host specified in the domain part of the
> address." -- as there is no way to be sure that a given envelope sender
> address really *is* rewritten according to the same scheme. So unless
> there will be some widely accepted rewriting scheme, I am unsure whether
> cutting the middleman is the right thing to do just yet.

Shortcutting is the part I haven't yet implemented. I did choose a prefix
"srs0+" instead of "bounce-" or "bounce+" since many people on the
internet already use "bounce". The 0 is intended to be some sort of
'format' or 'version' number. The implementation offers both a fully
bijective scheme which satisfies this requirement, and there will be (by a
day or so's time) an implementation which uses the shortcut scheme
described.

There is also a backing-store based system which allows SRS to operate as
desired with short addresses yet conform fully to RFC2821.

> I think we can get to a widely accepted rewriting scheme if we can agree
> on a inter-hop delimiter and a first-word prefix indicator.

At http://www.anarres.org/projects/srs/ there are some notes on
delimiters. There are two arguments here:

a) Put the original sender email address first.
* This allows a remote shortcut server to cut out just the email
address without caring about what other information is embedded in
the rewritten address.
b) Put the original sender email address last.
* This avoids all the problems of escaping and munging, and makes it
considerably simpler and easier to implement.

I have preferred (b) because if SRS is to be a standard format, then
everyone will know where to find the email address anyway. This leads to
the question of:

What information should be encoded into the SRS address?

Clearly required fields:
* Original sender.
* Cryptographic hash with secret to avoid remailing.

Useful fields:
* Timestamp.

Useless fields (and hence not included in my version):
* Hitcount - this is no use unless we have backing store anyway, and if
you have backing store, just use one of the backing store based modules.

Any other fields?

I hope this isn't covering too much ground that's been seen before, my
apologies if I do.

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@Ë`Ì{5¤¨wâÇSÓ°)h

Meng Weng Wong <mengwong@dumbo.pobox.com> [2004-02-06/12:49]:
> I believe the author of RPR is now on this list with us. Welcome!

I am, yes, thanks.

Though let me clarify: when I refer to return path rewriting (RPR), I
mean the general concept of rewriting the return path (the envelope
sender), not my particular implementation of an RPR scheme. SRS would be
another possible RPR scheme.

But on to SRS...


Shevek <spf@anarres.org> [2004-02-06/18:19]:
> I did choose a prefix "srs0+" instead of "bounce-" or "bounce+" since
> many people on the internet already use "bounce". The 0 is intended to
> be some sort of 'format' or 'version' number.

Makes sense to me.


[delimiters]
> b) Put the original sender email address last.
> * This avoids all the problems of escaping and munging, and makes it
> considerably simpler and easier to implement.

[from the web site]
> * The sendhost is before the senduser because we know that there are
> many characters which cannot appear in a domain name. We are free to
> use any of these characters as our separator character. In this
> implementation, we choose + but this is configurable.

I can see some possible issues here.

- Make sure SRS works with IDN. Currently, with IDNA punycode, the only
thing to note is the double dashes (--) in domain names.
But if we assume that the domain name can only consist of [a-zA-Z.-],
we might have a nasty surprise when one day somebody decides to
extend the characters allowed in SMTP to those allowed by DNS (though
little known, DNS itself imposes no restrictions on the character set
whatsoever; see RFC 2181 for details).

- Make sure SRS works with the full address specification as per RFC
2821/2822, including the quoted form (which can get nasty when taking
messages apart and replacing parts).

- Escaping some parts of the address, and not others, seems to be more
prone to implementation errors: too much en/decoding, or not enough.

- The same applies to relying on the parsing precondition that a domain
name must not contain certain characters for parsing. It seems to be
prone to implementation errors.

For these reasons, I am all in favour of encoding everything, including
the original sender domain, and not relying on any assumptions about the
domain names, neither for the encoding/decoding of special characters,
nor for the parsing. If SRS is going to be a widely adopted standard, it
should be as "clean" and straightforward to implement as possible.


> Clearly required fields:
> * Original sender.
> * Cryptographic hash with secret to avoid remailing.
>
> Useful fields:
> * Timestamp.

The timestamp is not just useful, but clearly required if we want to
stop old addresses from working (ie, stop replay attacks). Not too long
after sending messages, Return-path:-headers will end up on websites,
public mailing list archives and the like, and will thus be harvested
and used by spammers. In my opinion, a timestamp (well, a "datestamp"
at least) is a must.

Encoding the full unix epoch time into the address would serve as the
required "datestamp", and additionally allow to track the time the
message was resent, and make sure that the same rewritten address will
not be used too many times.


> Useless fields (and hence not included in my version):
> * Hitcount - this is no use unless we have backing store anyway, and
> if you have backing store, just use one of the backing store based
> modules.

I agree. This is one of the things that made me dislike Mail:SRS as it
were. I could not figure out what the supposed benefit of it was, and
how it was used when receiving bounces.

We should not forget that it is possible that a single forwarded message
results in multiple legitimate bounces. Consider a /etc/aliases style
forwarding to multiple addresses. If several of them fail, you'd want
all bounces back, not just the first one. There is no way for us to
decide how many bounces will be legitimate. (The same is true for the
database backend variant -- I would consider limiting the number of
bounces harmful)


> Any other fields?

Have you considered the special case of locally generated messages with
legitimately faked envelope sender address, with nonlocal receipient?
You don't have an original receipient to encode in the "alias address
local part" field. In my scheme, I just use the full receipient address
(encoded). This way you always have the receipient of the message
encoded in the address. The reason why somebody might want to know the
receipient address is tracking the abuse of valid bounce addresses.

One case where this kind of rewriting will happen: say I ssh into my
private host "gateway.private.net" and use mutt or whatever local MUA,
or I use Squirrelmail via the web, (which both can directly use the
local sendmail command for sending the message). Then I send mail with a
nonlocal sender address "me@somecorp.com" because it is impossible or
inconvenient to use somecorp's real mailserver to send the message.
While this scenario may look somewhat constructed, I really do have that
scenario here (both webmail and local MUA), and I'm confident that
people will find other reasons why we must cater for rewriting such
messages too.


In case I've babbled about things you've all discussed over and over
already, feel free to point me to appropriate messages in the archive.

Cheers
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
OpenPGP key id 0x804A06B1 (1024/4096 DSA/ElGamal)
144D 6A5E 0C88 E5D7 0775 FCFD 3974 0E98 804A 06B1
!->

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

Daniel Roethlisberger <daniel@roe.ch> [2004-02-06/22:47]:
> -------
> To unsubscribe, change your address, or temporarily deactivate your
> subscription, please go to
> http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGHÝÜîU;±¤Ö¤Íµøˆ¡

Oh, this list manager software is broken. It adds the list footer to
signed text/plain parts, which obviously breaks both S/MIME and PGP/MIME
digital signatures. It should instead add a second top-level text/plain
MIME part containing only the footer.

Cheers,
Dan


--
Daniel Roethlisberger <daniel@roe.ch>
OpenPGP key id 0x804A06B1 (1024/4096 DSA/ElGamal)
144D 6A5E 0C88 E5D7 0775 FCFD 3974 0E98 804A 06B1
!->

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

On Fri, Feb 06, 2004 at 11:01:43PM +0100, Daniel Roethlisberger wrote:
|
| Oh, this list manager software is broken. It adds the list footer to
| signed text/plain parts, which obviously breaks both S/MIME and PGP/MIME
| digital signatures. It should instead add a second top-level text/plain
| MIME part containing only the footer.
|

You're right, this has been added to the to-do list and assigned.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

Shevek wrote:

>Hi, as previously stated in my "introductory" mail, I am the author of new
>prototype versions of Mail::SRS, a Perl implementation of SRS. My notes
>and thoughts from the time of writing that code may be found at
> http://www.anarres.org/projects/srs/
>
>
Minor note: If you used Tie::MLDBM to talk to MLDBM, then it would be
*really* easy to switch over to using DBI to access an SQL database (it
would be a one statement change).

Philip

--
Philip Gladstone
* Check out the live pondcam at http://pond.gladstonefamily.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

----- Original Message -----
From: "Meng Weng Wong" <mengwong@dumbo.pobox.com>
To: <spf-devel@v2.listbox.com>
Sent: Friday, February 06, 2004 6:54 PM
Subject: Re: [spf-devel] Moving ahead with SRS

> On Fri, Feb 06, 2004 at 05:49:54PM +0000, Mark wrote:
> |
> | You want SRS in the sendmail spf-milter too? I will gladly add it.
> |
>
> Awesome, thanks Mark.

Adding SRS to spf-milter will be easy, when it comes to decoding addresses.
The actual SRS rewriting, however, will be hard, if not impossible. Because
the Milter API provides no way to change the envelope-from of the current
transaction.

Short of capturing the entire message, and resending it with a different
envelope, SRS encoding may prove impossible within a Milter.

The problem is, that SRS encoding may also prove too difficult to stick in a
ruleset. I will really need to rake my brain over this. Decoding, at least,
is something I will do this weekend (that will at least prevent spf-milter
from bouncing valid SRS envelope-froms).

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Fri, Feb 06, 2004 at 12:27:35PM -0500, Meng Weng Wong wrote:
>
> We also need to draft a new SRS spec that has a clearly defined
> delimiter so that multple forwarding hops can perform reduction. Once
> we have a clearly defined delimiter and an indicator prefix, SRS and RPR
> and other schemes can play well together.

Defining a delimiter so that the original sender can be
visibly encoded in the local part of the forwarding sender may
neither be possible:

a. In the sense that this will leave the combined address not easily
parseable by humans after 2 or 3 forwarding stages including
use of escapes.

b. In the sense that the length of the combined string will
soon exceed the maximum allowed in certain standards after
multiple hops.

Nor is it, in my view, strictly neccessary. Given the need
to supply a message dependent cookie somewhere in the
message headers, to prevent the forwarder becoming an open
relay, why not just use this cookie as the local part of the
forwarding sender address ? An objection to this is that
it is opaque. Well, for some purposes (legitimate use of
anonymous forwarding) this opacity is required. For other
purposes, the forwarding route will be much more easily
parseable by a human if it involves an additional and optional
header such as:

X-Forwarding-Route: wq7g423yt@anonymiser.com
controversial@opinion.list.org
student02374158@alma.mater.edu

Where anonymiser.com has forwarded the message (giving no
previous routing details) to opinion.list.org , which
distributed it to addresses including one at alma.mater.edu
which presumably forwarded it to the final recipient.

I don't see how replay attacks could be prevented without some
kind of database, at a minimum sufficient to prevent a cookie
being used in a bounce message more than once.

Could this database be achieved in a lightweight manner,
e.g. similar to the way sendmail organises its outgoing message
queue spool ? Presumably the need to retain the information
needed to bounce an undeliverable message times out after a
certain period, e.g. 7 - 14 days.

For a forwarding MTA which handles 10million message deliveries a day,
storing 2K per message forwarded for a fortnight would require 140Gbytes of
disk, so assuming suitable efficiency and concurrency of data
structures, the database requirement does not seem unreasonable at
first glance. This 2K per message would be sufficient for a 1K file and a few
directory entries per message, assuming use of a tiered filesystem tree
giving sufficient concurrency, and reasonable speed of data access.

An alternative approach using a conventional SQL database for heavily
used listserver MTAs would probably need more memory to reduce
the level of disk access. I think we may, when this line of analysis
is complete, have to accept the need for some degree of hardware upgrade
for some very heavily used and currently fully or near fully-utilised
listservers, but the performance requirements do not appear to
me to be unmanageable at this stage.

Richard Kay

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h