Ok, maybe is will not be too hard. Looking at the online Exim
documentation, it looks like there IS a acl_smtp_helo acl. In the book I
have, from 2003, there is not.
Please respond to spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
cc: (bcc: Dan Mitton/YD/RWDOE)
Subject: Re: followup: Re: [spf-discuss] libspf2 sample programs
LSN: Not Relevant
User Filed as: Not a Record
UNCLE !!
Ok, I'm convinced. Now, how to do it. I'm running SPF (1.999) with Exim
(4.60-1) (on Sun Solaris 8, Perl, 5.6.1 but I don't think that matters).
In the example acl provided with Mail::SPF::Query, if doesn't even have a
MAIL command check, but that seemed easy enough to fix:
acl_smtp_mail = acl_check_mail
acl_check_mail:
# Do SPF test
drop !acl = spf_mail_acl
accept
spf_mail_acl:
# Check envelope sender
warn set acl_m8 = $sender_address
deny !acl = spf_check
warn message = Received-SPF: $acl_m8 ($acl_m7)
accept
(really the same as spf_rcpt_acl)
but how do I get at the HELO command? I don't think there is an exim
acl_smtp_helo acl.
Also, drop vs deny?? I think I would want to drop a connection as soon as
I know its a spammer, but is there a reason to use deny instead?
Thanks,
Dan
Please respond to spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
cc: (bcc: Dan Mitton/YD/RWDOE)
Subject: Re: followup: Re: [spf-discuss] libspf2 sample programs
LSN: Not Relevant
User Filed as: Not a Record
(this time with the formatting gink removed - sorry)
What about RFC 1123 where it states:
5.2.5 HELO Command: RFC-821 Section 3.5
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.
The HELO receiver MAY verify that the HELO parameter really
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.
It is very important to keep e-mail policy separate from e-mail MTA
correctness. If I violate the above in my MTA, then I may not be
compliant with RFC 1123, and my MTA is not "correct"ly implemented.
However, as an e-mail admin, I have an
absolute right to refuse or accept any mail I want to, on any basis I
choose.
The MTA is governed by RFC 1123, and it needs to give the admin
the choice of accepting the mail.
SPF is a tool that can be used by the admin to determine which
e-mail to accept based on policy.
-dgl-
Sender Policy Framework: <http://www.openspf.org/>http://www.openspf.org/
Archives at <http://archives.listbox.com/spf-discuss/current/
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
-------
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
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
-------
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