Graham Murray <graham(_at_)webwayone(_dot_)co(_dot_)uk> writes:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
It would seem the best solution for MTA servers sharing multiple domains
would be to NOT publish any SPF or Sender-ID records. This would
protect clients that might be harmed by repudiation services. I have
yet to see such cautionary statements about publishing records when
clients share common servers of differing domains.
Although SPF could help reduce some of the spoof address bounces,
Sender-ID will not. Neither SPF nor Sender-ID allows an effective means
to abate abuse. Transparent redirection of the SMTP protocol does this
effectively however. If the trade-off is for less spam or fewer options
of which email address someone may use, I'll opt for less spam. It is
folly to insist all mail servers will map on a one-to-one basis to
domains just to suit Sender-ID repudiations.
When an MTA serves multiple domains, either all of the email is
originated on the MTA and all of the domains are under common
ownership - which is possible but I suspect uncommon. In which case
the problem is internal to the running of that system and outside the
scope of this WG. Or, the emails are passed to the MTA, or MSA on the
same system, by SMTP clients on other systems. Therefore, could (and
should not) the shared MTA perform checks to ensure that the
submitting system is authorised to send mail for the domain in the PRA
of submitted email. Could the shared MTA not set up a 'private'
(internal either to the MTA or to the origanisation running the MTA)
DNS containing SPF, Sender-id or Domain-key records to indicate which
systems are authorised to submit email (to the shared MTA) on behalf
of each domain? Or, even easier especially where mail is submitted
from dynamic IP addresses, require SMTP AUTH and have a separate
authorisation 'user' for each domain.
Which domain is to be isolated by the provider? Now, in addition to the
onerous limitations of the closed Sender-ID records for domains the
customer may employ, (closed as this shared mode then requires) you want
the provider to place a more severe restriction of a single domain
regardless of the Sender-ID record? Either providers decide to endure the
expensive overhead and check each message's Sender-ID record and sign
contracts with Microsoft, or do nothing. Either way, there is no
indication what was done nor that the MTA is shared. If some identity
then becomes unfairly indicated to a repudiation checker, who is at fault?
The message will likely say "Message blocked by company 'X' repudiaton
services." Will company 'X' claim provider 'Y' MUST use Sender-ID? In
other words, 'Y' MUST sign contracts with Microsoft or they become a party
to the suit? I don't see how Company 'X' is protected assuming the world
is using Sender-ID, especially when everyone is prohibited from using
Sender-ID unless a contract is signed. Even if this were a free
technology, there is still no method to check if the message had been
checked at every shared point nor the related safety of an open record.
-Doug