On Tue, Nov 14, 2006 at 12:54:42AM +0000, Jon Grant wrote:
Of course, smart ISPs won't accept mail for
"kslkjashdflgshd(_at_)example(_dot_)com"
and thus won't accept responsibility for it. Those ISPs that do accept
responsibility for such a message are the ones responsible for causing
harm to the forged domain owners. Spamcop...
Does Spamcop accept, and then reject then? Or were you meaning Spamcop
is the solution?
I ment spamcop is part of the solution. If enough people complain
about such misdirected bounces, maybe the ISP comes to its senses.
Could you recommend any ISP which has a configurable Reject 554 policy?
I'd like to be able to list envelope-sender and the displayed From:
addresses which I want to be Rejected with code 554. I get many junk
mails from online shops and such that I once ordered things from. Its
often not possible to get them to stop sending me their newsletters etc
unfortunately.
Spamcop...
I don't ment spamcop as ISP, I ment you should submit your unwanted junk
mail to spamcop. Of course, if you opted in to such mail, you should
unsubscribe yourself. But certain spammers^Wsellers ask you for your
email address so they can send you shipping info. They "forget" to tell
you that you will also receive countless advertisements. Such spammers,
er, sellers, deserve being blacklisted by spamcop.
I'd also like to Reject 554 connections to my MX server from IP
addresses which do not have reverse DNS set up on them, and connections
which say HELO with a different domain name to their Reverse DNS.
The first one is technically sound but you may end up refusing mail
you actually wanted to receive, the second one is against the RFCs.
Your mail, you can do to it what you want, but be aware that if you
don't want to play according to the rules, others won't.
Ah ok, so maybe the second one is best not implemented. At least should
we look for a fully qualified domain in the HELO?
The rules are (simplified list):
1) Parameter must be FQDN belonging to the connecting HOST (not isp)
2) If such a FQDN is not available or meaningless, an IP addres may
be used.
3) Do not reject solely based on reverse(ip_address) != parameter
HELO means "Hello, I am [...]", not "Hello there [...]". So, you can
reject if the other side uses your computer's name in its helo. You
know, for sure, that rule#1 is not obeyed. Dito for an ip address
belonging to you, or RFC1918 addresses.
If you know, by other means, that the remote side is lying (a russian
spammer saying "HELO hotmail.com") you can reject, based on rule#1.
If you are not sure, you can't reject. Example:
One host, multiple NICs.
somehost.example.com. A 192.0.2.1
somehost2.example.net. A 192.0.2.2
1.2.0.192.in-addr.arpa. PTR somehost.example.com
2.2.0.192.in-addr.arpa. PTR somehost2.example.net
The primary hostname for this host is somehost.example.com however it is
connecting to you via its other network card.
Unfortunately, RFC2821 allows this host to say "HELO somehost.example.com"
You see IP address 192.0.2.2 connected, find name somehost2.example.net,
read "HELO somehost.example.com" and notice the discrepancy. You may log
this discrepancy, but you may not reject BASED ON THIS.
It is perfectly legal to reject for other reasons, even as far as RFC2821
is concerned.
You may reject, but that does not mean you should. Perhaps you are
not willing to reject all mail sent by your friends, your peers, your
boss, whatever.
I've got my own linux server running on a fixed IP, I'm just not so sure
what software packages to setup to allow all these ideas to work.. Do
you know of any easy to use system, with a web interface which I could
install on my server to manage it? I'm using postfix at present, but I
can change to a different MTA if I need to.
Well, I would suggest postfix because it has a reasonable track record
and is not too difficult to configure[*]. I am no fan of click and drool
interfaces, because I want my application to be able to do what I want,
not what the interface designer wants.
[*]for simple setups. It can be difficult as well!
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735