Re: Does marid-submitter-02 really make sense?

["Douglas Otis" <dotis@xxxxxxxxxxxxxx>]

Graham Murray <graham@xxxxxxxxxxxxxxx> writes:
> Douglas Otis <dotis@xxxxxxxxxxxxxx> 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