Eric S. Raymond wrote:
You left out the
S: .
after the "Mode set to SMTP" line. :-)
I was using EHLO as an example, so it's probably not quite right either
way. Still, you can see what I'm getting at.
I think this is an intelligent question to be raising. Now let me ask
the next one: is there any reason this shouldn't be an SMTP extension?
This doesn't seem too bad, but it does raise the question of whether we're
shoving too much stuff into the MTA. Suppose you want a host that does
nothing but handle these requests, and it doesn't accept mail. It would
have to speak enough SMTP to do this, but then reject the usual commands
which are involved with actually sending mail.
Personally, I don't mind having to run another daemon for something like
this, but I also see that most admins would probably object to it.
Random thought: you could outsource the server side to a company that
would run it with lots of well-connected boxes. You pay them some small
amount and they answer questions about mail attempts involving your
domain. You just tell them which hosts are valid and they handle it for
you. If you are the victim of a forgery, they're the one that has to deal
with the incoming verification load.
That is, why shouldn't I be able to do this:
telnet example.exploits.org 25
I assume you're figuring out who to connect to based on the existing "try
MX records and fall back on the A" scheme. This is very easy, but it also
puts the load of rejecting forgeries on your inbound mail hosts.
Perhaps a scheme where you try a SRV record for this specific service
first, then do the MX/A thing after that would be better. That way you
could have a separate group of hosts which do nothing but handle the
checks.
S: 550 DENIED Not a valid IP for bogus(_at_)example(_dot_)exploits(_dot_)org
C: QUIT
I'd like to supply a TTL somewhere so the client could cache it. This
would obviously require some kind of process to remember such things on
the client side of the network, but it would minimize the load.
Organizations like hotmail would probably want a short TTL so they could
revoke access and have it become effective right away. I'd use one that's
much bigger, on the order of a week or more, since my mail situation does
not change that much.
Side note: this might solve the 'traveling mailman' problem if you made
your user authenticate from their remote host before sending mail. It
might work a bit like POP-before-SMTP: run fetchmail to hit the ISP, and
now that host is allowed to send mail as that u(_at_)h for awhile.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡