ietf-smtp
[Top] [All Lists]

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

2013-02-27 19:45:04
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.

Clients? I don't think you understand the nature of this extension if you
think it's about what the client sees. XCLIENT communicates information from
the originating client to the final destination server, not the other way
around.

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.)

None of this has anything at all to do with XCLIENT.

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.

The general problem you appear to be looking at doesn't appear to have anything
to do with the problem at hand.

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

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

That's sufficient.

[...]

- 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

So? It's hardly news that standards get ignored - sometimes for valid reasons,
often for no good reason at all - in the field.

I have no idea why Google choose to do this, and I frankly don't feel the need
to spend any time looking in to it further.

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.

Nothing you or Rolf has said has demonstrated that they 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.

And I quite simply disagree.

                                Ned
_______________________________________________
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>