[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mail-Transmitter RR



note that the proposal as written is about smtp source repudiation, not spam.
while it's true that spammers are the most common forgers of smtp source
information, they are by no means alone.

also note that this proposal uses a DNS RR but is not about DNS itself, and
there may be a more appropriate forum for the discussion than namedroppers.
(i wasn't going to release my proposal without further private review, but
the question came up here today and so i sent my working draft in answer.)

> I do like this approcah, though this method only protects against spammers
> (etc) forging those domains that exist and apply this method to protect
> themselves.

exactly.  if i've learnt anything about making spam more difficult, more
expensive, and less effective, it's that it has to be done by someone with
"standing" (such as the recipient or someone whose domain is being forged.)

> While the 'sender domain must exist'  test already acts well
> to protect against use of non-existing domains, spammers will still be free
> to use existing domains that are not thusly protected in their mails.

it is the responsibility of anyone whose domain is forged to add a MAIL-FROM
under this proposal.  there are 30,000,000 of them but at least the ones who
are common targets of forgery will have a way to put an end to it.

> There will also be issues with sites that have off-site MX hosts to hold 
> mail in case of downtime, viz:
> 
> 	$ORIGIN domain.example.
> 	@	IN MX 10 mail
> 		IN MX 20 mail.myisp.example.
> 
> Both hosts in such a configuration will have to be able to perform the
> test, as both may receive mail directly from the sender's MAIL-FROM
> MTAs and the final destination MTA cannot perform this test on mail ...

understood and agreed.  however, i can't think of a less onerous way for a
domain holder to protect themselves against forgery of this kind, and i see
forgery of this kind as a huge huge huge source of domain-holder pain.


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>