As far as I can see, I've seen at least three issues coming along within
this thread, so I suggest to split up this thread into multiple threads
to prevent confusion. I have identified the following issues:
1. the OP started this thread by describing a problem that, in his
opinion, exists when backup MXs are abused by spammers to circumvent
AS measures implemented on the primary MX. So if this problem
exists, this is problem #1.
This is a general area, not a specific technical problem.
2. later on, this thread turned in another direction:
Ned wrote:
True, it requires a certain amount of finesse, and some standards in
this area
would definitely help, but there is nothing intrinsicly impossible to
do here.
to which Evert answered:
Actually that is an interesting idea. The backup MX could act as
an SMTP proxy as long as it can maintain a connection with the
primary. That would also sort out your observation on address
checking.
I assume, Ned, that the problem you want to address, is the lack of
standards in the area of communication between an SMTP proxy and an
SMTP server, where the context of the original connection from SMTP
client to SMTP proxy need to be transferred to the SMTP server, is
that right?
No, not really. I want to address the general problem of passing connection
context through relays, proxies, secondary MXes (which can operate either
as relays, proxies, or something in between), HTTP web service mail
submission interfaces, and probably some variants of IMAP submit.
I fail to see why all of these things, which deal in essentially the
same information, should require separate standards.
If not, please describe what in your view is the problem
at hand. And whatever the problem description is, it is problem #2
which is distinct from the original posed problem.
On the contrary, there is substantial overlap. A key aspect of the
circumvention of the AS solution on the primary once the message makes
it there is the lack of original connection context. Havi
3. another item was the problem that backup MXs and primary MXs often
do not implement the same (AS/AV) policies and the problem of
providing the backup MX with address information that is available
to the primary. It's nice to discuss it here (I have no suggestion
for another venue), but I wonder whether this topic belongs on the
ietf-smtp list.
Your #2 and #3 have the essentially the same solution. As such, I do not much
value in pursuing them independently. However, I do see value in pursuing the
problem of the primary providing information to make the secondaries life
easier, e.g., by improving its ability to validate addresses.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp