[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: one uninformed comment about 2.99.49p6 (acceptdns +)



> I haven't tried running p6 yet, but I already have a comment :-)
> This is for anyone who is thinking about using the acceptifdns + option
> in the policydb.
> 
> Earlier (a few weeks ago), _my_ ISP (i.e., interlog.com, not uunet.ca)
> tried to do that (with Sendmail 8), but immediately got a lot of complaints
> from users. The problem is that a lot of people now deliberately set their
> addresses to invalid addresses in an attempt to block spam. Activating
> acceptifdns (correct me if I am wrong) would block all such legitimate mail
> from reaching your site.

	Like others have commented so far, although I too have sympathies
	for those spam blockers, I did develope the mechanism after
	experiencing SPAM-relaying at nic.funet.fi with bogus source
	address -- and I do mean A LOT of them.

	As to why nic.funet.fi didn't before have complete blocking before
	was that I simply didn't know all valid clients...  That was one
	of the reasons I built attributes:
		acceptifmx
		acceptifdns
		senderokwithdns

	The first two are RECIPIENT test attributes, the third is sender
	verify attribute.   If the recipient address is not valid, there
	is no point in accepting it at all.  The sender MAY be invalid,
	and the recipient addresses are ok -- however just bloody too many
	spams are like that...

	I do know, that this is an arms race -- once the spammers are
	smart enough, they will start using valid DNS registered addresses,
	and sometimes even using domains that they have no connection with
	( I have seen a few instances of  @utu.fi,  and @nic.funet.fi :-(  )

	At IETF DRUMS working group (now at Munich) there is a proposal of
	systems being allowed to ignore the RFC-821 source routes, that is,
	address of form:
		@a,@b:c@d
	could be stripped of the source-route part, and be used as:
		c@d
	never mind that "@a" is supposed (in RFC-821) to be stripped
	only by the "a" system...

> Anyone have any more informed statements about this?
> --
> Ambrose C. Li <acli@mingpaoxpress.com> Programmer-analyst (sysadmin)

/Matti Aarnio <mea@nic.funet.fi>