Error message

  • Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1895 of /home/magiksys/sites/blog.magiksys.net/includes/database/query.inc).
  • Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1895 of /home/magiksys/sites/blog.magiksys.net/includes/database/query.inc).
  • Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1895 of /home/magiksys/sites/blog.magiksys.net/includes/database/query.inc).
  • Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1895 of /home/magiksys/sites/blog.magiksys.net/includes/database/query.inc).

The struggle against SPAM is a political problem more than a technical one

I thing SPAM is more a political problem than a technical one !
A lot of smart technical solutions exist for a long time now but SPAM remains a problem.
Main mail service providers like Google and Hotmail could choose and impose new rules in mail exchange to the community, by rejecting mails from servers not following them. Then I thing SPAM would be reduced to the minimum.

My solution below is deliberately superficial because a real solution would require long debate of mail gurus to avoid any weakness. I'm only one and maybe not a guru :-)

My favorite solution combines RBL and SPF pointers. Not RBL of IP addresses as usual but thanks to SPF we could black list domain names.
If rejecting mail from SPF unaware domain would be the rule, any SPAM could be easily attributed to a domain name and its company owner.
Repeated SPAM flood would damage the corporate image of the company and incapable IT managers would be replaced by capable ones.
I thing that black listing domains instead of IP addresses would make each IT administrator more responsible about its own LAN security and usage
to avoid viruses and PC zombies.
RBL and SPF are now common, reliable and easy to use. Lot of of mail actors are already using them.

SPF only handle SMTP MAIL FROM value and not the more visible mail header From field.
To give more sense of responsibility to IT administrator and domain owner we should take care of the header From field too.

Maybe we could start at our humble level to warn every senders about their SPF unaware domain name and hope
main mail actors will embrace a common and consensual solution against SPAM in the future.
Open source could provide some software to prepare the ground and RBL providers could handle domain names besides of IP addresses.

It could works this way : ( I know this is incomplete and contains weakness ! )

When a RBL provider get SPAM from a valid SPF enable domain, he log the domain sender besides of the IP address.

Any SMTP server must drop mail coming from SPF unaware domains.
During a fixed transition period, mail could be gently returned to sender with an appropriate warning.
Then the server check the IP address of the sender against the SPF pointers of both domain of SMTP MAIL FROM
and header From field. If the SPF check succeed, then both domain can be checked against a RBL.

Of course SPF is not designed to check header From field ! Mailing lists and program generated mails sometime fake the
header From field for good purposes. If it this can not be handles locally by tuning the SPF pointer, this must be handled by
other way and maybe technical solution to invent.

Add new comment