----- Original Message -----
From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, March 29, 2004 2:27 PM
Subject: Limited scope of work
Therefore, we once again ask the participants of this list to focus on
the following identities:
2821 HELO/EHLO domain
2821 MAIL FROM
2822 From:
2822 Sender:
New structure/RR's in .arpa *
I really am having a hard time following you guys with this. What is it you
are looking for here? All I would like to see done is that the 2821
functional specifications make the 2821 entities requirements. With
extremely few exceptions, it is only the illegal systems that are not
honoring this.
We also ask that participants consider and list the following
ramifications regarding deployment issues:
1) Amount of change in software components (MDA, MTA, MUA, DNS servers,
DNS resolvers).
I hope this isn't view as self-selving, but I can only speak for our product
development experience in this area for the last year. Since we are 100%
focused in maintaining a long industry technical and legal tradition for
ethical mail hosting and transport integrity, at the network level , any
acceptance/rejection is based on technical compliancy and
acceptance/rejection on the mail content is based on the system admin
policies.
MTA:
Changes were required in MTA (SMTP receiver) to add "hooks" at each state
point in the SMTP state machine:
IP connect --> validation
HELO --> validation
MAIL FROM ---> validation
RCPT TO --> validation
DATA --> validation
Early anonymous access management work concentrated on providing a MAIL
FROM hook passing IP, HELO and MAIL FROM to perform a validation process.
We used a RBL, DMP and a CBV (callback verifier).
By anonymous access, this means that if the session is trusted, this new
validation logic was skipped.
We learn very quickly the overhead was just TWO high, especially given the
fact that 80% of all spam is spoofed and to a large degree, the domains are
NXDOMAIN.
It then because obvious that if RCPT TO was not acceptable, then the need
for validation was not necessary. Since we were recording ~30% RCPT TO
unknown users, the sender validation hook was delayed until RCPT TO: was
known.
Again, since this is for anonymous access, RCPT can only be for local or
hosted domains.
This new delayed sender validation at RCPT was a tremendous overhead
reduction improvement
We also offer a DATA hook, but like I said, this logic is system admin
defined. We are not in the mail interpretation business.
DNS:
As far as DNS resolvers, we did find, I guess, bugs in handling TXT records.
It dealt more in making sure the TXT records were entered correctly,
escaping crlf characters, etc.
2) Configuration complexity.
The following were options engineered based on the above work:
Options related to "What comes first?" Which testing method should be done
first, accredation vs LMAP?
Options to define which Domains to test. The fact that the majority of the
systems will not have DNS records, especially the spammers, and the fact
that the biggest LMAP benefit is Local domain spoof protected, options were
provided to define which domains to test.
Options on how to test the ridiculous "soft fails" or "neutral." Accept or
continue testing, if any.
Options to define DNS response time.
Options to record history, cache results, half lifes.
3) Current use cases that will no longer be viable.
RBL was formerly done at the SMTP level. This was moved to the HOOK as
part of the delay validation until RCPT is known improvement. That is
probably it for us.
4) Needed infrastructure changes.
No input.
5) Considerations for use in both IPv4 and IPv6.
No input.