Problem(s) to solve:
- (Detecting and) Rejecting Bad Guys,
- Reducing Computers for Reception (turning off backups when primary is up),
- Uniformity and Consistent Filtering Methods across MXes,
- RFC Error with implications that different MX and its order has a
direct correlation to quality of mail acceptance.
I'll be interested in correcting the possible RFC "Error" first. Later,
a possible BCP for reducing the TCO without losing scale. That may
include good suggestions for hosting on other sites (an integrated
cloud) and ideas to communicate authorized hosting information.
--
HLS
On 2/28/2013 4:49 AM, Rolf E. Sonneveld wrote:
On 02/28/2013 02:28 AM, Ned Freed wrote:
[...]
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.
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.
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? 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.
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.
Please add to this list if you think it's not complete.
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp