ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Reject messages on backup mail exchangers when primary MX is online

2013-02-26 06:52:27
On Mon 25/Feb/2013 23:01:18 +0100 Ned Freed wrote:

IMO these two problems are interrelated. The more a backup MX is
configured with the settings and policies of the primary, the less the
need for context transfer.

Of course they are interrelated operationally. But I've yet to see that
the solution to one is related to the solution of the other in any way.
Given that the information flow in each case is in the opposite
direction,
I don't see how they could be.

At most the other problem might inform to some extent the design of a
standardized XCLIENT sort of extension. But that's all.

I'm not clear if clients should see any difference.  An SMTP proxy set
up for submission, for network design reasons, say, would tend to be
as transparent as possible.  A backup MX besieged by a foreign relay
might want to ask the client if it did try the primary beforehand.  (I
have no idea what kind of answer can be sought by that question, but
it seems to be similar to what the OP was wondering about.)

So I again repeat: Let's divide an conquer here. Rather than getting
sidetracked into the myriad nuances of MX behavior that are at most
minimally relevant.

But by blindly tackling xclient alone, we risk to find a solution that
won't fit well within the general problem.

I strongly recommend reading up on XCLIENT as a starting point.

I just saw http://www.postfix.org/XCLIENT_README.html  More pointers?

[...]

- Results of SPF and DKIM verification

Not needed; we have standardized headers for communication of
authentication results.

There is some confusion, though.  Google, for example, seems to be
taking off on the trail of X-Original-Authentication-Results:
https://sites.google.com/site/oauthgoog/mlistsdkim

Both RFC 5451 and RFC 6377 mention the possibility to sign an
Authentication-Results field.  However, the easiest approach that an
MTA can take to guarantee the trustworthiness of its own A-Rs is to
remove (or rename) any existing A-R, which breaks the signature if the
field is signed --MTAs not natively supporting DKIM don't care.

Frankly, I view the backup MX case as one of less interest than
that of SMTP proxies. And as you and others have noted there are
other problems that need solving in the MX space. But why should we
insist on solving them all at once?

I think Rolf just wanted to see how much interrelated those problems
are.  As for the mail flows, they both overlap with the "forwarding
service", as depicted in http://fixforwarding.org/wiki/mail_flows
Shredding some light on that part of the picture might have its own
merits, irrespectively of which slice of the problem is going to be
solved first.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>