Re: Exchange mucking with the headers

John Honan <[email protected]> Wed, 31 Aug 2011 16:02:40 +0100
Newsgroups gmane.mail.spam.hashcash
Message-ID <CAJ0Aoy9hqhnogo+=G5aXfL33Tth1R3P9SL2aYDBKYyAFJ+1Svw@mail.gmail.com>
--20cf3078130466e3ef04abce6b1c
Content-Type: text/plain; charset=ISO-8859-1

Could it be the Exchange 2010 Address Rewriter agent messing with the
header?

http://technet.microsoft.com/en-us/library/aa996806.aspx#SMTP

You can check out the rewriter rules for your server;
http://technet.microsoft.com/en-us/library/aa997185.aspx

But if this is the default behaviour of Exchange, then a more robust
solution would be... a workaround!

John.

On 31 August 2011 15:47, Aaron Toponce <[email protected]> wrote:

> I've come to the knowledge that Exchange is mucking with the mail headers,
> stripping out any duplicate fields. This is troublesome for me, as sending
> a mail to multiple recipients, means minting many Hashcash tokens, and
> placing each token in the header with "X-Hashcash". There may be more than
> one present. However, Exchange changes "X-Hashcash" to "x-hashcash", and
> removes any dupe "x-hashcash" fields.
>
> I could stamp each mail upon delivery, rather than mail creation, but that
> would meach changing the way I handle SMTP with Mutt, and that's not
> something I'm really interested in persuing. AFAIK, there is no "standard"
> against duplicate header fields, so my multiple "X-Hashcash" tokens should
> be just fine.
>
> Has anyone else noticed this? Is there a server-side setting on Exchange
> that prevents Exchange from mucking with the headers?
>
> Thanks,
>
> --
> . o .   o . o   . . o   o . .   . o .
> . . o   . o o   o . o   . o o   . . o
> o o o   . o .   . o o   o o .   o o o
>



-- 
www.payback.ie
Irish Payroll Software

--20cf3078130466e3ef04abce6b1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could it be the Exchange 2010 Address Rewriter agent messing with the heade=
r?<br><br><a href=3D"http://technet.microsoft.com/en-us/library/aa996806.as=
px#SMTP">http://technet.microsoft.com/en-us/library/aa996806.aspx#SMTP</a><=
br>
<br>You can check out the rewriter rules for your server; <a href=3D"http:/=
/technet.microsoft.com/en-us/library/aa997185.aspx">http://technet.microsof=
t.com/en-us/library/aa997185.aspx</a><br><br>But if this is the default beh=
aviour of Exchange, then a more robust solution would be... a workaround!<b=
r>
<br>John.<br><br><div class=3D"gmail_quote">On 31 August 2011 15:47, Aaron =
Toponce <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">aa=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x;">
I&#39;ve come to the knowledge that Exchange is mucking with the mail heade=
rs,<br>
stripping out any duplicate fields. This is troublesome for me, as sending<=
br>
a mail to multiple recipients, means minting many Hashcash tokens, and<br>
placing each token in the header with &quot;X-Hashcash&quot;. There may be =
more than<br>
one present. However, Exchange changes &quot;X-Hashcash&quot; to &quot;x-ha=
shcash&quot;, and<br>
removes any dupe &quot;x-hashcash&quot; fields.<br>
<br>
I could stamp each mail upon delivery, rather than mail creation, but that<=
br>
would meach changing the way I handle SMTP with Mutt, and that&#39;s not<br=
>
something I&#39;m really interested in persuing. AFAIK, there is no &quot;s=
tandard&quot;<br>
against duplicate header fields, so my multiple &quot;X-Hashcash&quot; toke=
ns should<br>
be just fine.<br>
<br>
Has anyone else noticed this? Is there a server-side setting on Exchange<br=
>
that prevents Exchange from mucking with the headers?<br>
<br>
Thanks,<br>
<font color=3D"#888888"><br>
--<br>
. o . =A0 o . o =A0 . . o =A0 o . . =A0 . o .<br>
. . o =A0 . o o =A0 o . o =A0 . o o =A0 . . o<br>
o o o =A0 . o . =A0 . o o =A0 o o . =A0 o o o<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br><a href=3D"http:=
//www.payback.ie">www.payback.ie</a><br>Irish Payroll Software<br>

--20cf3078130466e3ef04abce6b1c--