On Wed, 23 Jun 2004 11:23:45 +0100 (BST), Shevek wrote: in
On Wed, 23 Jun 2004, Meng Weng Wong wrote:
On Tue, Jun 22, 2004 at 05:20:36PM -0400, Meng Weng Wong wrote:
| | Also maybe as part of the setup testing, send an email to a
| | "test" email account (at pobox maybe), after jumping through a
| | few hoops for security, which then reports on all aspects of
| | the configuration.
| |
| | This could warn of potential issues:
| |
| | * No SPF record
| | * SPF record gives a FAIL
| | * SPF record is outrageous (+ALL, big IP range...)
| | * Lack of PTR records (or IP encoded PTR records).
| | * IP is designated as MTAMark=No
| | * IP is listed as DUL/DHCP in major RBL lists
| | * others based on policies of AOL etc...
<snip>
If anyone gets to this before I do, please recontribute the
code (possibly offlist to spf(_at_)anarres(_dot_)org) so I can include
it on > http://www.libspf2.org/
Just to put some of the context back into this thread, when I
posted this suggestion for an outbound MTA compliance checker,
it was partially in frustration to the poor quality of HELO's
being issued, particularly by Exchange implementations.
A more complete list of checks, as inferred in the original post:
* No SPF record
* SPF record gives a FAIL
* SPF record is outrageous (+ALL, big IP range...)
I believe this has yet to be agreed
* HELO/EHLO is not a FQDN (or is a xyz.local)
* HELO/EHLO domain does not resolve to an A or MX record
* HELO/EHLO domain tested for SPF as above
* HELO/EHLO domain is same as RCPT TO domain
I know config this is not liked by some
* Lack of PTR records (or IP encoded PTR records).
* IP is designated as MTAMark=No
* IP is listed as DUL/DHCP in major RBL lists
* others based on policies of AOL etc...
The checks will need to be agreed (and defined) by consensus,
particularly those which I have noted on the list. Other
peoples suggestions need to be considered and added.
Also please note that security for this check is important to
stop it being potentially abused (the jump through hoops thing).
I see at least two potential ways of carrying this out:
* Script run on email after delivery, results returned to "an
address", this has obvious issues if abuse is to be avoided.
The check could be run after a mailing list type subscription,
also the listener would have to whitelist the RCPT TO address.
* Checks run before DATA, and issues reported back as a 55X
style report, avoiding the return address abuse issue. This
method though may require a dedicated listener to achieve, and
I'm sure using the 55x mechanism will not be welcome by some,
and possible limitations on the report size (unless linked to
an expiring web page).
The results also being stored in a database may be good,
particularly if it gives a before and after overview, we all
like pretty graphs, even better when they mean something.
Regards
Karl Prince
______________________________________________________________
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)