> That's easy enough. The case where someone has 2 IMAIL servers,
> A and B, and each on separate networks. A is backup for B and B
> is backup for A.
Backing up for different domains, I suppose? I understand why you
would want to do this double-duty kind of thing (to save money), but
it's non-traditional.
> I have not tested Eric's solution of removing B_domain from the ACL
> of A_domain but I assume Eric has tested this and that he is
> correct.
It does work as he described; I ran a test after his post.
> Regardless, there is something puzzling about the way in which IMAIL
> handles the percent-sign e-mail address.
Hm. I don't think so. RFC 2822 does note that support for source
routing is deprecated, but source routes MAY still be honored if the
MTA decides to do so. Imail's continued acceptance of the '%' as a
source routing signifier is surely linked to its own need for that
syntax for virtual hosts. The fact that Netscape POP3 clients login as
user%virtual@primary is no coincidence: in Imail's architecture, the
'%' is an important signifier of the need to break down the initial
local-part ('account') into a secondary local-part and domain.
> In the IMAIL case and where "account" has a percent sign in it the
> IMAIL backup server (B_domain in my example) is perfectly capable of
> parsing the address, determining the domain (A_domain), looking in
> the HOSTS file to find A_domain's IP address, and checking the ACL
> to see if relaying is allowed for A_domain.
Yep.
> So it seems to me that IMAIL really does know how to find the domain
> for this address. It makes sense that the part of the address that
> is not the domain is the account name.
It makes RFC-mandated sense that the part of the RCPT after the '@' is
the destination domain, so, after checking to make sure that the mail
isn't going to itself, Imail forwards the mail promptly to the
destination (after checking the ACL to see that such relaying is
allowed).
RFC 1123, while coming out strongly against source routing, says:
> An embedded source route is sometimes encoded in the "local-part"
> using "%" as a right-binding routing operator. For example, in:
>
> user%domain%relay3%relay2@relay1
>
> Only the target host (in this case, "relay1") is permitted to
> analyze the local-part "user%domain%relay3%relay2".
...
> What should happen it seems to me is that IMAIL should check to see
> if this entire account name exists for the A_domain and if it does
> it then should deliver the message.
As far as the RFCs go, we're indeed in SHOULD-vs.-SHOULD territory
here.
> If the account name does not exist then it should bounce it. And
> this is what happens in the situation where you send the same
> message to the A_domain server directly and not from the backup mail
> server.
No, it's not. Only if the A_domain server won't relay for you. No
matter who you are, MTA or MUA, if Imail relays for you by IP or
address, you are free to use source routing in your RCPT TO:. In fact,
if you use a@b@c, IMail kindly translates that into a%b@c for the
remote server's clarity.
> But in the case where the message is sent from the backup mail server
> IMAIL treats the account name as a new message address.
In all cases, actually. See above.
> I'm surprised IMAIL handles the message differently where there is no
> ACL for the backup.
It handles it differently with regard to relaying, but it handles the
'%' exactly the same.
> Regardless the fact remains that IMAIL is handling the ACCOUNT part of
> the address differently when it is received from a backup mail server
> and when it has a percent sign in it.
Nope (sorry, I know I'm getting annoying with that :).
> It is an interesting issue at any rate.
Agreed. Hope I gave you some helpful details.
-Sandy
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
