On Mon, 22 May 2006, Chris Meadors wrote:
> >
> > Just playing with BATV i noticed that it could conflict with
> > some (mine in that case) SPF setups. If i publish SPF records
> > like "v=spf1 redirect=%{l}._spf.ols.es" which use the local part
> > of the envelope sender to generate a new dns request then batv
> > encoded addresses like prvs=david/0297929b3b@??? produce a
> > dns query on prvs=david/0297929b3b._spf.ols.es which include
> > two forbiden charactes (= and /) I noticed that some implementations
> > will just use david/0297929b3b._spf.ols.es for the query but this
> > also includes the forbiden character "/" Taking apart the obvious
> > problem with %{l} (allowed email characters do not match dns allowed
> > characters), it will be nice to be able to change the way exim
> > generates batv signatures
>
> I've had servers reject my MAIL FROM: addresses because they don't like
> the '=' or '/' either. Now that is pretty stupid of them to tell me
> what I can or can't use in my own addresses. The BATV draft did specify
> those characters. Probably because they were not commonly used in local
> parts. The problem becomes that valid hostname character: [a-z], [0-9]
> and '-' are found very often in local parts. So how would one encode a
> BATV signature in a way it could easily be parsed back out of the
> complete address while only using those characters?
>
$work uses[1]:
somehashedcodebits---origlocalpart@???
Make it lots easier to search logs, as the last time I looked
at the draft BATV spec, it was more like:
origlocalpart---somehashedcodebits@???
[1] and we're pretty happy with it, thanks
--
--------------------------------------------------------
Dave Lugo dlugo@??? LC Unit #260 TINLC
Have you hugged your firewall today? No spam, thanks.
--------------------------------------------------------
Are you the police? . . . . No ma'am, we're sysadmins.
