Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. SPF>
  3. Devel
average size of incoming localparts
mengwong at dumbo
Feb 11, 2004, 12:17 PM
Post #1 of 11 (3506 views)
Permalink
Here's a distribution of the lengths of localparts, domains, and
total-length from the pobox mailstream earlier today.

20040211-14:09:12 root@flatbox:/export/shared/logs/syslog# grep from= maillogs/current/mail.info.00 | grep -v colander | grep -v bounce.pobox.com | head -100000 | perl -nle 'my ($localpart,$domain) = /from=<(\S+)\@(\S+)>/ or next; $localpart[length $localpart]++; $domain[length $domain]++; $total[length ($localpart) + length ($domain) + 1]++ } { for my $i (1 .. $#localpart) { printf "localparts of length %2d: %6d %s\n", $i, $localpart[$i], "-" x ($localpart[$i]/100) } for my $i (1 .. $#domain) { printf "domains of length %2d: %6d %s\n", $i, $domain[$i], "-" x ($domain[$i]/100) } for my $i (1 .. $#total) { printf "totals with length %3d: %6d %s\n", $i, $total[$i], "-" x ($total[$i]/100) } '
localparts of length 1: 34
localparts of length 2: 244 --
localparts of length 3: 2461 ------------------------
localparts of length 4: 4890 ------------------------------------------------
localparts of length 5: 5450 ------------------------------------------------------
localparts of length 6: 6383 ---------------------------------------------------------------
localparts of length 7: 6458 ----------------------------------------------------------------
localparts of length 8: 5459 ------------------------------------------------------
localparts of length 9: 5082 --------------------------------------------------
localparts of length 10: 8445 ------------------------------------------------------------------------------------
localparts of length 11: 3341 ---------------------------------
localparts of length 12: 3119 -------------------------------
localparts of length 13: 2648 --------------------------
localparts of length 14: 2419 ------------------------
localparts of length 15: 1824 ------------------
localparts of length 16: 1418 --------------
localparts of length 17: 747 -------
localparts of length 18: 1242 ------------
localparts of length 19: 396 ---
localparts of length 20: 885 --------
localparts of length 21: 451 ----
localparts of length 22: 271 --
localparts of length 23: 298 --
localparts of length 24: 883 --------
localparts of length 25: 240 --
localparts of length 26: 366 ---
localparts of length 27: 269 --
localparts of length 28: 257 --
localparts of length 29: 125 -
localparts of length 30: 226 --
localparts of length 31: 144 -
localparts of length 32: 100 -
localparts of length 33: 127 -
localparts of length 34: 125 -
localparts of length 35: 72
localparts of length 36: 206 --
localparts of length 37: 119 -
localparts of length 38: 869 --------
localparts of length 39: 154 -
localparts of length 40: 153 -
localparts of length 41: 71
localparts of length 42: 79
localparts of length 43: 98
localparts of length 44: 156 -
localparts of length 45: 149 -
localparts of length 46: 214 --
localparts of length 47: 172 -
localparts of length 48: 264 --
localparts of length 49: 226 --
localparts of length 50: 248 --
localparts of length 51: 90
localparts of length 52: 98
localparts of length 53: 84
localparts of length 54: 61
localparts of length 55: 65
localparts of length 56: 58
localparts of length 57: 12
localparts of length 58: 9
localparts of length 59: 11
localparts of length 60: 7
localparts of length 61: 14
localparts of length 62: 2
localparts of length 63: 7
localparts of length 64: 3
localparts of length 65: 0
localparts of length 66: 0
localparts of length 67: 2
localparts of length 68: 1
localparts of length 69: 0
localparts of length 70: 0
localparts of length 71: 5
localparts of length 72: 0
localparts of length 73: 2
localparts of length 74: 0
localparts of length 75: 0
localparts of length 200: 1


domains of length 1: 0
domains of length 2: 1
domains of length 3: 2
domains of length 4: 0
domains of length 5: 136 -
domains of length 6: 798 -------
domains of length 7: 3461 ----------------------------------
domains of length 8: 2733 ---------------------------
domains of length 9: 5433 ------------------------------------------------------
domains of length 10: 5193 ---------------------------------------------------
domains of length 11: 6483 ----------------------------------------------------------------
domains of length 12: 11097 --------------------------------------------------------------------------------------------------------------
domains of length 13: 5521 -------------------------------------------------------
domains of length 14: 5219 ----------------------------------------------------
domains of length 15: 2960 -----------------------------
domains of length 16: 5050 --------------------------------------------------
domains of length 17: 4214 ------------------------------------------
domains of length 18: 1860 ------------------
domains of length 19: 1577 ---------------
domains of length 20: 2129 ---------------------
domains of length 21: 2000 --------------------
domains of length 22: 717 -------
domains of length 23: 558 -----
domains of length 24: 1772 -----------------
domains of length 25: 604 ------
domains of length 26: 290 --
domains of length 27: 81
domains of length 28: 120 -
domains of length 29: 96
domains of length 30: 142 -
domains of length 31: 90
domains of length 32: 10
domains of length 33: 7
domains of length 34: 232 --
domains of length 35: 1
domains of length 36: 13
domains of length 37: 1
domains of length 38: 3
domains of length 39: 3
domains of length 40: 1
domains of length 41: 0
domains of length 42: 0
domains of length 43: 1



totals with length 1: 0
totals with length 2: 0
totals with length 3: 0
totals with length 4: 1
totals with length 5: 1
totals with length 6: 0
totals with length 7: 0
totals with length 8: 0
totals with length 9: 10
totals with length 10: 70
totals with length 11: 344 ---
totals with length 12: 489 ----
totals with length 13: 793 -------
totals with length 14: 1179 -----------
totals with length 15: 1766 -----------------
totals with length 16: 2640 --------------------------
totals with length 17: 2910 -----------------------------
totals with length 18: 3498 ----------------------------------
totals with length 19: 3982 ---------------------------------------
totals with length 20: 3879 --------------------------------------
totals with length 21: 4765 -----------------------------------------------
totals with length 22: 4064 ----------------------------------------
totals with length 23: 4319 -------------------------------------------
totals with length 24: 4461 --------------------------------------------
totals with length 25: 4206 ------------------------------------------
totals with length 26: 2231 ----------------------
totals with length 27: 3859 --------------------------------------
totals with length 28: 2676 --------------------------
totals with length 29: 2066 --------------------
totals with length 30: 1287 ------------
totals with length 31: 1962 -------------------
totals with length 32: 1577 ---------------
totals with length 33: 981 ---------
totals with length 34: 649 ------
totals with length 35: 599 -----
totals with length 36: 767 -------
totals with length 37: 468 ----
totals with length 38: 505 -----
totals with length 39: 751 -------
totals with length 40: 389 ---
totals with length 41: 532 -----
totals with length 42: 342 ---
totals with length 43: 257 --
totals with length 44: 268 --
totals with length 45: 233 --
totals with length 46: 129 -
totals with length 47: 172 -
totals with length 48: 356 ---
totals with length 49: 202 --
totals with length 50: 144 -
totals with length 51: 128 -
totals with length 52: 111 -
totals with length 53: 841 --------
totals with length 54: 108 -
totals with length 55: 140 -
totals with length 56: 139 -
totals with length 57: 77
totals with length 58: 94
totals with length 59: 94
totals with length 60: 56
totals with length 61: 42
totals with length 62: 56
totals with length 63: 75
totals with length 64: 55
totals with length 65: 30
totals with length 66: 35
totals with length 67: 25
totals with length 68: 45
totals with length 69: 93
totals with length 70: 88
totals with length 71: 146 -
totals with length 72: 145 -
totals with length 73: 270 --
totals with length 74: 235 --
totals with length 75: 225 --
totals with length 76: 90
totals with length 77: 106 -
totals with length 78: 81
totals with length 79: 40
totals with length 80: 43
totals with length 81: 36
totals with length 82: 16
totals with length 83: 14
totals with length 84: 18
totals with length 85: 9
totals with length 86: 11
totals with length 87: 2
totals with length 88: 5
totals with length 89: 1
totals with length 90: 1
totals with length 91: 2
totals with length 92: 0
totals with length 93: 0
totals with length 94: 1
totals with length 208: 1

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
mengwong at dumbo
Feb 11, 2004, 12:36 PM
Post #2 of 11 (3492 views)
Permalink
On Wed, Feb 11, 2004 at 02:17:41PM -0500, Meng Weng Wong wrote:
| Here's a distribution of the lengths of localparts, domains, and
| total-length from the pobox mailstream earlier today.
|
| 20040211-14:09:12 root@flatbox:/export/shared/logs/syslog# grep from= maillogs/current/mail.info.00 | grep -v colander | grep -v bounce.pobox.com | head -100000 | perl -nle 'my ($localpart,$domain) = /from=<(\S+)\@(\S+)>/ or next; $localpart[length $localpart]++; $domain[length $domain]++; $total[length ($localpart) + length ($domain) + 1]++ } { for my $i (1 .. $#localpart) { printf "localparts of length %2d: %6d %s\n", $i, $localpart[$i], "-" x ($localpart[$i]/100) } for my $i (1 .. $#domain) { printf "domains of length %2d: %6d %s\n", $i, $domain[$i], "-" x ($domain[$i]/100) } for my $i (1 .. $#total) { printf "totals with length %3d: %6d %s\n", $i, $total[$i], "-" x ($total[$i]/100) } '
| localparts of length 64: 3
| localparts of length 65: 0
| localparts of length 66: 0
| localparts of length 67: 2
| localparts of length 68: 1
| localparts of length 69: 0
| localparts of length 70: 0
| localparts of length 71: 5
| localparts of length 72: 0
| localparts of length 73: 2
| localparts of length 74: 0
| localparts of length 75: 0
| localparts of length 200: 1

Who is in VIOLATION, you ask? The BBC, no less! Oh, the humanity.

20040211-14:14:22 root@flatbox:/export/shared/logs/syslog# grep from= maillogs/current/mail.info.00 | grep -v colander | grep -v bounce.pobox.com | perl -nle 'my ($localpart,$domain) = /from=<(\S+)\@(\S+)>/ or next; print if length ($localpart) > 64;'
Feb 11 00:01:31 integer/integer postfix/qmgr[16925]: 73F5234B83: from=<f5f2b1505b23e6c524831c0383ff6ca282e5a2d74a075dc49779cf8e1012b604_server@ebs.bbc.co.uk>, size=39487, nrcpt=1 (queue active)
Feb 11 00:01:56 integer/integer postfix/qmgr[16925]: 3E2D534D17: from=<679c620668e9496d682bf89aace4077dc25f76e1a664966543da5b9fdb921045_server@ebs.bbc.co.uk>, size=8095, nrcpt=1 (queue active)
Feb 11 00:01:56 integer/integer postfix/qmgr[16925]: 3162434907: from=<679c620668e9496d682bf89aace4077dc25f76e1a664966543da5b9fdb921045_server@ebs.bbc.co.uk>, size=8318, nrcpt=1 (queue active)
Feb 11 00:01:58 wintergreen/wintergreen postfix/qmgr[7977]: D83B2254CC: from=<3026053671fa11fe5d36c0bb0a79ee7ffa6d4c86da0be399f1c83a1a5a7d46dc_server@ebs.bbc.co.uk>, size=6780, nrcpt=1 (queue active)
Feb 11 00:02:04 icicle/icicle postfix/qmgr[2292]: 4B5F643321: from=<c1e639e9ce8ba5739212f95ab6ff62f32175000a32c7436bff9a5ef1157c5547_server@ebs.bbc.co.uk>, size=48491, nrcpt=1 (queue active)
Feb 11 00:06:29 icicle/icicle postfix/qmgr[2292]: 98DB242B02: from=<offers-F693046D660E916A0B818C67B19A29C9-george.p.williams@¸âb,¼ó³ÏúÜ‚ôþüoØ~Qï¹2E µFSÜC>, size=8425, nrcpt=1 (queue active)
Feb 11 00:19:11 wintergreen/wintergreen postfix/qmgr[7977]: D08F7254DB: from=<securityjobs-return-warn-1076453910.cbegjadodcidjkohhhkp-jrroca@éý\>Ÿ2ãŽDpð¶ wæ ø>, size=8822, nrcpt=1 (queue active)
Feb 11 00:19:11 wintergreen/wintergreen postfix/qmgr[7977]: DD0CF254B0: from=<securityjobs-return-warn-1076453910.cbegjadodcidjkohhhkp-jrroca@éý\>Ÿ2ãŽDpð¶ wæ ø>, size=9042, nrcpt=1 (queue active)
Feb 11 00:23:04 integer/integer postfix/qmgr[16925]: C3E5634E42: from=<b.TailWaggingOffer.0-2e1f46c-173c.alumni.utexas.net.-stephanie_brew@16.moosq.com>, size=1793, nrcpt=1 (queue active)
Feb 11 00:27:57 boggle/boggle postfix/qmgr[16306]: 28B0837861: from=<b.javaexpressions.d-2e317c4-5333.alumni.utexas.net.-russell_phillips@e.ss01.net>, size=3516, nrcpt=1 (queue active)
Feb 11 00:31:44 icicle/icicle postfix/qmgr[2292]: 36C7B433C0: from=<IMCEAX400-c=US+3Ba=+20+3Bp=NG+3Bo=CA801+3Bdda+3ASMTP=IMCEAX400-c=US+2B3Ba=+2B20+2B3Bp=NG+2B3Bo=TX850+2B3Bdda+2B3ASMTP@¸ތU³~DÔ9l܉e6…åî†hßYg€5¤Ùëɳì©ÃĈˆš(O#„°Kè€È¥ìã–øFeb 11 00:36:45 integer/integer postfix/qmgr[16925]: 39B7034EE9: from=<b.TailWaggingOffer.0-2e1f46d-173c.alumni.utexas.net.-will_doubrava@04.moosq.com>, size=4701, nrcpt=1 (queue active)
Feb 11 00:48:40 wintergreen/wintergreen postfix/qmgr[7977]: 68070252DC: from=<sentto-2703372-1546-1076475118-michael.storch@ÍÒ§1ÉDŸ©U•X¹HZp
} çúž!†Ó—…ʳCæ>, size=41692, nrcpt=1 (queue active)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
wayne at midwestcs
Feb 11, 2004, 12:43 PM
Post #3 of 11 (3431 views)
Permalink
In <20040211191741.D33564AB@dumbo.pobox.com> mengwong@dumbo.pobox.com (Meng Weng Wong) writes:

> Here's a distribution of the lengths of localparts, domains, and
> total-length from the pobox mailstream earlier today.

Very interesting.

Here is what I come up with:

There were a total of 70609 envelope-froms

Of which, 99% are <= 74 bytes

97% are <= 64 bytes

95% are <= 52 bytes

90% are <= 38 bytes

85% are <= 33

80% are <= 30

75% are <= 28

66% are <= 26

50% are <= 23


So, if we can keep the SRS overhead under 12 bytes, we can keep 95% of
the email addresses under the 64 byte limit. If the over head is 26
bytes, we keep 90%. Things start failling pretty quickly over 31
bytes of overhead


-wayne


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
wayne at midwestcs
Feb 11, 2004, 12:56 PM
Post #4 of 11 (3438 views)
Permalink
In <20040211191741.D33564AB@dumbo.pobox.com> mengwong@dumbo.pobox.com (Meng Weng Wong) writes:

> Here's a distribution of the lengths of localparts, domains, and
> total-length from the pobox mailstream earlier today.


More analysis:

The overhead of SRS includes an extra domain name, so the break down
of domain name lengths are:

99%: <= 34 bytes

95%: <= 23 bytes

90%: <= 19 bytes

85%: <= 18 bytes

80% <= 16 bytes


The current format of SRS is:
"SRS1+" <domain> <hash> "+" <timestamp> "+" <envelope-from>

That is 7 bytes of literal strings

If we use the 90% mark for domain names, we have to add in 19 bytes.
(19 bytes will probably give us more than 90% of the mail forwarder
domain names though. Most use short domain names.)

That give SRS an overhead of 26 bytes plus the hash/timestamp stuff.
The 90th percentile for envelope-froms allowed 26 bytes of overhead. :-<


It looks like squeezing characters may be worth while....


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
mengwong at dumbo
Feb 11, 2004, 1:05 PM
Post #5 of 11 (3472 views)
Permalink
On Wed, Feb 11, 2004 at 01:56:28PM -0600, wayne wrote:
|
| The current format of SRS is:
| "SRS1+" <domain> <hash> "+" <timestamp> "+" <envelope-from>
|
| That is 7 bytes of literal strings
|
| It looks like squeezing characters may be worth while....
|

I suggest we drop the "+" and reformat to

"SRS0+" <timestamp> <hash> <domain> "+" <envelope-from>

I will also put out an I-D saying "hey, let's get rid of the 64 byte
limit entirely."

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
wayne at midwestcs
Feb 11, 2004, 1:26 PM
Post #6 of 11 (3499 views)
Permalink
In <20040211200549.GA6151@dumbo.pobox.com> Meng Weng Wong <mengwong@dumbo.pobox.com> writes:

> On Wed, Feb 11, 2004 at 01:56:28PM -0600, wayne wrote:
> |
> | The current format of SRS is:
> | "SRS1+" <domain> <hash> "+" <timestamp> "+" <envelope-from>
> |
> | That is 7 bytes of literal strings
> |
> | It looks like squeezing characters may be worth while....
> |
>
> I suggest we drop the "+" and reformat to
>
> "SRS0+" <timestamp> <hash> <domain> "+" <envelope-from>
>
> I will also put out an I-D saying "hey, let's get rid of the 64 byte
> limit entirely."


We could save another byte by using "SRS0" instead of "SRS0+".


I think using a timestamp granularity of one day was a good choice,
and we should keep it.

I think that most systems will not be interested in accepting bounces
after 60 days, so we could use only 6 bits for the timestamp if we add
the Julian date into the private key as a salt.


Thinking about it more, I would say that we want something like 20 or
more bits of hash.

So, 6 + 20 = 26 bits = 5.03 base36 digits

Hmmm.. 6 base36 digits is just over 31 bits

So, we could use 8 bits for the timestamp and 23 bits for the hash


So, we would have:

"SRS1" <6 bytes of hash/timestamp> <domain> "+" <envelope-from>

That would be 11 bytes of SRS overhead, plus 19 bytes for the domain,
which leaves 34 bytes for the envelope-from. (64 - 11 - 19 = 34)

The envelope-from length of 33 bytes was the 85th percentile.


That isn't too bad, especially when you consider that most forwarders
(the extra domain name) will be less than the 19 byte average.


Other things we could do:

* Use a base greater than 36. The local part can, after all, have a
lot more characters than just [a-z0-9]

* Use the fact that hostnames have a far more limited set of
characters than the local part. By recoding the characters, we
might save a little bit. It would be UGLY, but...



-wayne









-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: average size of incoming localparts [ In reply to ]
spf at anarres
Feb 11, 2004, 2:19 PM
Post #7 of 11 (3429 views)
Permalink
On Wed, 11 Feb 2004, Meng Weng Wong wrote:

> On Wed, Feb 11, 2004 at 01:56:28PM -0600, wayne wrote:
> |
> | The current format of SRS is:
> | "SRS1+" <domain> <hash> "+" <timestamp> "+" <envelope-from>
> |
> | That is 7 bytes of literal strings
> |
> | It looks like squeezing characters may be worth while....
> |
>
> I suggest we drop the "+" and reformat to
>
> "SRS0+" <timestamp> <hash> <domain> "+" <envelope-from>

The minimal unambiguous encodings are:

SRS0TTHHHH+domain+local-part
SRS1domain+TTHHHH+domain+local-part
or
SRS1TTHHHH+domain+domain+local-part

I'm not sure what impact the removal of the + after the SRSn has on
simplistic implementations in mailers. However, it's still quite easily
implementable. I will put this into v0.16. We are also going to shorten
the hash to 4 bytes base64/36. This gives between 21 and 24 bits of hash.
We are going to make this a configurable option, thus the length of the
hash is not known, and a + is needed between the hash and the domains.

The other catch is that if we remove the separator after SRS0, then it's
not necessarily possible to tell the difference between an SRS0 address
and a base64 encoded database address. However, this shouldn't be an issue
since any rewriting host will know which scheme it implements.

> I will also put out an I-D saying "hey, let's get rid of the 64 byte
> limit entirely."

This would be good on principle.

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
Re: average size of incoming localparts [ In reply to ]
daniel at roe
Feb 12, 2004, 3:08 AM
Post #8 of 11 (3452 views)
Permalink
Shevek <spf@anarres.org> [2004-02-11/21:19]:
> > I suggest we drop the "+" and reformat to
> > "SRS0+" <timestamp> <hash> <domain> "+" <envelope-from>

> I'm not sure what impact the removal of the + after the SRSn has on
> simplistic implementations in mailers.

I would vote against removing that +. It makes simplistic
implementations significantly easier on MTA which can be configured to
treat those + suffixes as variations on local mailboxes, for example via
.qmail files, and it only saves a single byte per message. I am
convinced that the ease of implementation is in this case more important
than saving this single octet of address length. Just my EUR 0.02.

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
Re: average size of incoming localparts [ In reply to ]
spf at anarres
Feb 12, 2004, 3:19 AM
Post #9 of 11 (3471 views)
Permalink
On Thu, 12 Feb 2004, Daniel Roethlisberger wrote:

> Shevek <spf@anarres.org> [2004-02-11/21:19]:
> > > I suggest we drop the "+" and reformat to
> > > "SRS0+" <timestamp> <hash> <domain> "+" <envelope-from>
>
> > I'm not sure what impact the removal of the + after the SRSn has on
> > simplistic implementations in mailers.
>
> I would vote against removing that +. It makes simplistic
> implementations significantly easier on MTA which can be configured to
> treat those + suffixes as variations on local mailboxes, for example via
> .qmail files, and it only saves a single byte per message. I am
> convinced that the ease of implementation is in this case more important
> than saving this single octet of address length. Just my EUR 0.02.

Well, the discussion went this way, then it went that way, then we
realised that in fact we wanted the one after the SRS\d so that we could
use a user called srs0 and one called srs1 in some MTAs. Then we replaced
+ with = anyway. Then I realised that somehow the SRS0 wasn't getting
removed in SRS1, even though all the documentation said it should.

So we are not going to remove the one removable = sign, and I fixed
everything else.

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
Re: average size of incoming localparts [ In reply to ]
jcouzens at obscurity
Feb 12, 2004, 3:26 AM
Post #10 of 11 (3434 views)
Permalink
go get slps shevek slps!!!!

hrhrhr

--
James Couzens,
Programmer

Current projects:
http://libspf.org

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

Attached Files:

Re: average size of incoming localparts [ In reply to ]
mengwong at dumbo
Feb 12, 2004, 3:39 PM
Post #11 of 11 (3447 views)
Permalink
On Thu, Feb 12, 2004 at 10:19:36AM +0000, Shevek wrote:
|
| Well, the discussion went this way, then it went that way, then we
| realised that in fact we wanted the one after the SRS\d so that we could
| use a user called srs0 and one called srs1 in some MTAs. Then we replaced
| + with = anyway. Then I realised that somehow the SRS0 wasn't getting
| removed in SRS1, even though all the documentation said it should.
|
| So we are not going to remove the one removable = sign, and I fixed
| everything else.
|

Some installations have to use + and other installations have to use -.

Maybe we can satisfy both types by imposing a mandatory ordering ---
that + always comes before -.

Once we do that we may be able to do a hybrid monstrosity:

srs0+-....

That satisfies both camps.

You wouldn't actually have to use both all the time --- you could start
off with + by default but if an MTA that prefers to use - gets involved
in the mix, it could switch the prefix to srs1+- and then everybody
would have to be liberal in what they received.

Just a thought. I hope this entire hack won't be necessary at all.

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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal