ietf-smtp
[Top] [All Lists]

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

2013-02-25 16:28:18
On 02/25/2013 05:27 PM, Ned Freed wrote:
>> Do those systems provide for keeping recipient lists in sync?
> That's a totally separate problem. And yes, it is a problem, and there
> are various ways to solve it, and it maybe makes sense to standardize one of
> them. Or not - it's a fundamentally harder problem to solve, with a lot
> more variabless.
>
>>   It is
>> too easy to abuse of a backup forced to accept any recipient.  OTOH, a
>> backup could stay disconnected from the primary for quite some time,
>> possibly transmitting mail to yet another backup which is able to
>> connect to the primary.  So it may make sense to have a copy of the
>> mailbox names at the backup MX.  What are the alternatives?
> Again, you're talking about a different problem. Let's please focus on the
> problem at hand, which is the transfer context from a secondary to a primary.

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.

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

...

As for the second problem, talking about context transfer, the following
comes to mind:

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

- original source IP address

Definitely needed, but the port should be included.

- original EHLO/HELO identity

Definitely needed.

- RFC5321.MailFrom information
- RFC5321.RcptTo information

Not needed; already part of the transaction.

- Results of SPF and DKIM verification

Not needed; we have standardized headers for commnunication authentication
results.

- Date/time of receipt at backup MX

Probably not needed. Received: fields should suffice unless someone can
articulate a reason for needing this information earlier in the SMTP
dialogue.

- et cetera

The main one you're missing is AUTH information. There are use cases
for XCLIENT beyond those for secondary MXes, which is another reason for
not using that lens to view this work.

Another possibility is using a shared secret for validation of this
information. Our XPEHLO extension does this.

Having said that, I still have not seen figures about how big this
problem really is. And _what_ exactly the problem is. Is it that backup
MXs attract spam? Do they and if so, how do we know that? Is it that the
use of a backup MX causes spam to be accepted, that would have otherwise
been blocked when it had been sent directly via the primary? Is it that
backup MXs causes backscatter? Let's first try to define the problem(s)
and then start to think about solutions.

Since when are these sorts of figures needed to justify this work? We have at
least two proprietary extensions that have been deployed to do this. I can
attest to the fact that both are in use in the field and also to the fact that
XCLIENT support has appeared as a requirement on RFPs.

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?

                                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>