Re: suggestions

[supp...@e4ward.com]

Thanks for the review and suggestions. Both the Reply-to and the From
headers are rewritten. If you are not seeing that, look for an
X-E4ward-Error header in the received mail which indicates that E4ward
had trouble parsing the header. Also there are a few other headers
that are rewritten to faciliate reply-to-all.

> Give users the option to disable address rewriting for specific
> aliases. That's because a user might have his or her personal address
> in the same domain as his disposable addresses,

If by personal, you mean the forwarding address for an alias (ie REA),
the REA can't be in the same domain as the one which is MX'd to
E4ward, otherwise mail would just forward back into E4ward instead of
being forwarded to a server where the mail account for the REA is
hosted.

[balazer]

> Thanks for the review and suggestions. Both the Reply-to and the
> From headers are rewritten. If you are not seeing that, look for an
> X-E4ward-Error header in the received mail which indicates that
> E4ward had trouble parsing the header. Also there are a few other
> headers that are rewritten to faciliate reply-to-all.

I see now. Originally my suggestion would be to leave the From: line
as-is, and insert or replace the Reply-to: line. But I suppose it is
just as good to replace both independently.

In my case I received messages through E4ward with no Reply-to line
at all. That was because the original message had no Reply-to line.


How are headers rewritten to facilitate reply-to-all? As far as I can
tell, when you reply to all, all recipients besides the person your'e
replying to will see an @reply.e4ward.com address among the recipients
- which of course they shouldn't, because if one of those people sends
mail to that address, it will look like it came from me when it didn't.
As far as I can tell, without some kind of special support from the
e-mail client, the only way to make address rewriting work completely
and correctly would be to have all outgoing mail go through a special
SMTP server that does the rewriting.

> If by personal, you mean the forwarding address for an alias (ie
> REA), the REA can't be in the same domain as the one which is
> MX'd to E4ward, otherwise mail would just forward back into
> E4ward instead of being forwarded to a server where the mail
> account for the REA is hosted.

I don't mean that my "real" e-mail address be in the same domain as the
E4ward domain.

What I'd hoped to do is have a single domain for myself. One alias in
that domain would be my personal address - not my "real" address, but
the address that I give to my friends, and the address placed in the
From: line of outgoing mail sent through my e-mail client. Of course
all of the mail addressed to my domain would be forwarded to my real
e-mail address - a mailbox in a different domain. For mail addressed
to my personal address, I would want reply address rewriting to be
disabled for two reasons: 1) it's not necessary, since rewriting would
just rewrite the address to be what it was already, and 2) for my
personal address, I would like my e-mail to work as normal e-mail
works, with reply-to-all and forwarding working like normal.

So the basic idea is that I'd like to be able to disable reply address
rewriting for specific aliases. I might, for example, have one
personal alias, and one alias for school business, both those aliases
behaving normally without any address rewriting. Address rewriting
would then work for all mail sent to any other address in my domain.

I'm sorry if I didn't explain that well. Does it make sense now?

[supp...@e4ward.com]

On 8/13/05, balazer
<google*balazer.co.uk*support1*e4ward.com*803*ld7i*3...@reply.e4ward.com>
wrote:

> How are headers rewritten to facilitate reply-to-all?

When mail is sent to your alias, e4ward rewrites each recipient header
(currently only From, To and Disposition-To, but there are others
that will be added to this list as necessary, eg mailing-list-from
headers).

The rewritten header address is of the form:
From: <fromaddress>*<alias>*xxxx-at-reply.e4ward.com.

When you reply to all, your mail client harvests the rewritten
addresses from these headers and puts them in the To or CC of the
outgoing mail.

> As far as I can
> tell, when you reply to all, all recipients besides the person your'e
> replying to will see an @reply.e4ward.com address among the recipients
> - which of course they shouldn't, because if one of those people sends
> mail to that address, it will look like it came from me when it didn't.

No. The mail goes to reply.e4ward.com, where the headers are rewritten
again, stripping off the reply.e4ward.com so recipients do not see
that. For example, say the headers on the reply look like this (using
-at- to avoid google mangling):

From: <balazar-at-example.com> (your REA inserted by your mail
client, will be masked)
To: <joe*joeREA.com*somealias*balazar.com*xxxx-at-reply.e4ward.com>,
< jane*janeREA.com*somealias*balazar.com*yyyy-at-reply.e4ward.com>

> As far as I can tell, without some kind of special support from the
> e-mail client, the only way to make address rewriting work completely
> and correctly would be to have all outgoing mail go through a special
> SMTP server that does the rewriting.

reply.e4ward.com is that special SMTP server :)

It would rewrite the above headers as follows before forwarding the email back.

From: somealias-at-balazar.com
To: <joe-at-joeREA.com>,<jane-at-janeREA.com>

> I would want reply address rewriting to be
> disabled for two reasons:
> 1) it's not necessary, since rewriting would
> just rewrite the address to be what it was already,

No extra charge :)

2) for my personal address, I would like my e-mail to work as normal e-mail
> works, with reply-to-all and forwarding working like normal.

I am not sure what you mean by normal other than 'not rewriting'.
Other things equal I do agree it would be nicer not to rewrite the
headers if not needed, because it does complicate things for you as an
E4ward user, but the effect to your recipients should be the same as
an un-rewritten alias - they only see the alias just they used when
they emailed you.

A disable feature would indeed be desirable but not trivial to
implement. However we will continue to look at it along with the other
enhancements we have planned for E4ward.com.

[balazer]

Thank you for your detailed response.

> When mail is sent to your alias, e4ward rewrites each
> recipient header (currently only From, To and Disposition-To,
> but there are others that will be added to this list as necessary,
> eg mailing-list-from headers).

I've looked at several messages received through an E4ward alias
addressed to multiple recipients. The From: and Reply-to: lines were
rewritten, but To: and CC: were not.

> I am not sure what you mean by normal other than 'not
> rewriting'. Other things equal I do agree it would be nicer not to
> rewrite the headers if not needed, because it does complicate
> things for you as an E4ward user, but the effect to your
> recipients should be the same as an un-rewritten alias - they
> only see the alias just they used when they emailed you.

By "normal" I mean that address rewriting would be turned off so that I
could write a message without fear of an @reply.e4ward.com address
being exposed, but per my above statement that is seemingly a separate
problem.

I guess it's true that rewriting addresses does not complicate things
for E4ward users too much. At my current stage as an early E4ward
user, the rewritten addresses look a bit unnatural and complicated -
though expect I will get used to that. Perhaps when an address is
rewritten, the original address could be added to the quoted portion,
so that the address appears in its unmodified form with the "at" sign
intact.

e.g.
"Bobby Brown <bobby...@isp.com>"
<bobbybrown*isp.com*myalias*mydomain.com*805*a11v*3...@reply.e4ward.com>

The extra text could be removed by reply.e4ward.com before the message
is sent.

There is one additional point that makes E4ward replies less than
transparent: the expiration of rewritten reply addresses. How long is
that expiration period? Will I be notified if I send a message to an
expired reply address? This is one problem that could be solved with
an authenticating SMTP server. (if the SMTP server could trust the
sender's identity, there would be no need to expire a reply address)

[supp...@e4ward.com]

> I've looked at several messages received through an E4ward alias
> addressed to multiple recipients. The From: and Reply-to: lines were
> rewritten, but To:

My mistake, I meant to write "Reply-To" , not "To", above.

>> and CC: were not.

Right you are. This will be fixed.

> At my current stage as an early E4ward
> user, the rewritten addresses look a bit unnatural and complicated -
> though expect I will get used to that. Perhaps when an address is
> rewritten, the original address could be added to the quoted portion,
> so that the address appears in its unmodified form with the "at" sign
> intact.

Some services do add the original address to the comment (which has
it's own complications) and make the rewritten address opaque (eg just
a database key essentially. We chose to make the address readable (if
somewhat complicated) to humans and programs. Since all the info is
already in the address, we don't duplicate it in the comment.

> How long is [the] expiration period?

around 3 weeks

> Will I be notified if I send a message to an
> expired reply address?

yes, the mail will bounce back to you with an expiration message. Note
that each reply gets a fresh reply address, so an active conversation
can continue well past the expiration of the original reply without
having to renew the address.

> This is one problem that could be solved with
> an authenticating SMTP server. (if the SMTP server could trust the
> sender's identity, there would be no need to expire a reply address)

Authentication is good when restricting access to the SMTP to certain
users (eg subscribers) and certain clients (eg not gmail) . The E4ward
SMTP is used by non-E4ward users and is completely transparent to
client.

The rewriting scheme was carefully chosen from many alternatives.
Actually it is a variant of SRS (Sender Rewriting Scheme, part of SPF
(Sender Policy Framework). Check out http://spf.pobox.com/ ,
http://spf.pobox.com/srs.html and http://www.libsrs2.org/srs/srs.pdf.
E4ward's variant of SRS is somewhat simplified and hopefully more
readable.