Apologies. I've been lurking and thinking for a while now, and have only now
been able to reasurrect old memories and form some sort of coherent thought
process. please bear with me - sometimes I don't explain an idea too well,
but the logic is there, somewhere! ;-)
I love the idea of SPF. But, despite including checks for all incoming mail
now, I am not too happy about implementation, which seems "clunky". Yes, it
works, and it gives a good idea of how it could work, but...
Worries:
1) The DNS lookup.
4.3.2.1.in-addr_smtp_client.example.com
Argh. An underscore in the hostname.
Yes, I can modify my MTA config to allow queries like this, but I've already
told it that it shouldn't be dealing with SMTP-broken hostnames. In allowing
SPF, I allow all queries. I am not happy about breaking this part of the
config, just to allow SPF.
Could we at least use the dash if we must use this method? Please.
2) The DNS RR
Several people have mentioned their dislike of using the TXT RR. I'm not a
purist, but I'm not sure this is the right thing. See below.
3) The Sender rewriting scheme.
I'm sorry. I think this is horrible, and just plain ugly. It seems far too
complicated, and therefore prone to breaking. I cannot stress this one point
too strongly. Sorry.
Thoughts around these are currently,
1) Do precursors of MX still exist?
RFC883 designated the RR's of
MD - A compressed domain name which specifies a host which
has a mail agent for the domain which should be able
to deliver mail for the domain
MF - A compressed domain name which specifies a host which
has a mail agent for the domain which will accept
mail for forwarding to the domain
MR - A compressed domain name which specifies a mailbox
which is the proper rename of the specified mailbox
MB - A compressed domain name which specifies a host which
has the specified mailbox
MG - A compressed domain name which specifies a mailbox
which is a member of the mail group specified by the
domain name
All seem to work OK under BIND, so I assume this is an obsolete record that
still officially exists If it exists, can these RR's not be used for
something useful? If these RR's are obsolete, but still allowable by reolver
libraries, we have a plethora of useful options here. Even the definition for
MD seems appropriate. Though it was written to imly that this was the host
receiving mail (AFAIK), it could eaqually be taken that the MD host is
authorised to send mail for that domain (Mail Delivery?)
Of course, the above RR's return HOSTNAMES, not IP addresses, if we use
RFC883. But, to test the principle, I have the following:
network.itmagic.ltd.uk 1D IN MD mail.itmagic.ltd.uk.
network.itmagic.ltd.uk 1D IN MD another.mail.com.
we have authorised two hosts to permit authorised sending of emails from
anyone(_at_)network(_dot_)itmagic(_dot_)ltd(_dot_)uk(_dot_) (You can test these
records - they should be
publically queriable)
2) Verification process. Are we looking at stopping spam full stop, or making
it difficult to forge and obfuscate who it is from? If it is the former, I am
cynical enough to believe we will fail. If the latter, at least if we can
properly authenticate the sender, we have enough info to persue further
action through complaints to ISP's/courts/etc. ISTM that checking the
envelope <mail from> address should be enough, and only using the address
specified in the headers in the case of the Null Sender <>.
Why? We already have the IP-address of the host connecting to us. If we use
rfc2821 §4.1.4, we can be sure that the HELO argument is the true hostname
(this alone cuts out a huge ammount of my spam).
For forwarding and mailinglists etc, though the From: header remains the same,
the sender doesn't. SPF on the envelope effectively means no horrid rewriting
when forwarding email to the end destination.
There is another potential benefit. Uptake will depend on sysadmins updating
their DNS records. Currently, the in-addr.arpa domain does't work for an
awful lot of hosts. I like SPF because I get a DNS log of
4.3.2.1.in-addr_smtp_client.itmagic.ltd.uk, telling me who is trying to forge
my email. But I am happy with, and competant in maintaining IP-address
mappings. Many admins clearly are not. If we relax the requirement, by
allowing an entry of
itmagic.ltd.uk 1D IN MD mail.itmagic.ltd.uk
a host can verify that the HELO argument matches the MD record. The sysadmin
would fail to get the report of potential forgeries, but everything else
would work as expected, and the RR's are a lot easier to maintain. Ease of
use and simplicity leads to greater uptake, and IP address can be used if
required. Also, with this, we eliminate to play DNS catchup with any outside
SMTP relaying service that we use. It is elegant.
On Fri, Oct 10, 2003 at 05:36:29PM -0400, Meng Weng Wong wrote:
2.4.3 PTR
...<snip>...
Sorry. This seems unneccesarily complicated. Af far as I am concerned,
rfc2821 §4.1.4 already deals with this, and gives the method as follows:
Take HELO argument. Find IP address accociated with it. Compare with
connecting IP-address.
This currently works (though you'll get into a flame war talking about it in
some circles). Helo verification is already possible. rDNS PTR's are
seriously lacking in the real world anyway.
The astute will notice that I am contradicting myself somewhat. This is
intentional. Though I really like the fact that a DNS query of
4.3.2.1.in-addr_smtp_client.itmagic.ltd.uk tells me who is attempting to
spoof my email, is this really necessary? What is going to be done with the
info, and is the benefit likely to be worth the effort? In this one area, SPF
cannot be a fusion of both RMX & DMP. There is a mutual incompatibility
between Joe-Job Notification and DNS Caching.
If I know that 192.168.0.5 is spoofing my email, what can I really do about
it? There will be a tendancy to panic, which will only be helped by a large
quantity of Valium. I could complain to the uplink provider, but I suspect an
awful lot of people are going to complain to the wrong postmaster.
3) Throwaway domains. Auto-tool if necessary. Razor/DSS & blocklists. I can't
see SPF doing this well.
4) SPF=SoftDeny
Can someone educate me on the benefit of this? I am sorry, but confused. If I
get mail from fred(_at_)test(_dot_)com, but SPF tells me the sending host isn't
authorised, why would test.com not want me to reject the mail as they have
obviously taken the time to implement SPF anyway? A default of DENY if any
SPF record is found and not verified seems easier.
5) Can anyone comment about the current status or progress of
Authorised Sender:
http://www.globecom.net/ietf/draft/draft-church-dns-mail-sender-01.html
Flames to the usual address. Comments followed with interest.
Regards,
Phil.
-------
Sender Permitted From: http://spf.pobox.com/
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/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com