Simple Python script as SMTP server for outgoing e-mails?

[Chris Angelico]

On Tue, Jul 23, 2013 at 6:06 PM, Duncan Booth
<duncan.booth at invalid.invalid> wrote:
> Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Tue, Jul 23, 2013 at 12:08 AM, Michael Torrie <torriem at gmail.com>
>> wrote:
>>> On 07/22/2013 06:51 AM, Chris Angelico wrote:
>>>>> Thanks for the tip. I didn't know about SPF
>>>>> http://en.wikipedia.org/wiki/Sender_Policy_Framework
>>>>
>>>> It's a great way of detecting legit vs forged mail. If anyone tries
>>>> to send mail purporting to be from anything at kepl.com.au and the
>>>> receiving mail server is checking SPF records, it'll be rejected
>>>> after one cheap DNS lookup. It's a simple and cacheable way to ask
>>>> the owning server, "Is this guy allowed to send mail for you?". (The
>>>> 192.168 block in my SPF record above is permitted to allow some
>>>> intranet conveniences; omit it unless you need it.)
>>>
>>> Yes setting SPF records will help your mail be accepted by other
>>> servers, but I disagree with your appeal to make mail server SPF
>>> handling as strict as your server does. SPF has problems in a number
>>> of situations which could cause legitimate mail to be rejected.  In
>>> my last job I could only use SPF as one spam factor, not as a basis
>>> for rejection.
>>
>> If legit mail is rejected for failing an SPF check, it's the sending
>> admin's problem, not yours. You should never have problems with it if
>> it's set up correctly. And since rejected mail gets reported to the
>> transmitting MTA, you don't need to drop it in a spambox or anything.
>> It's not spam, it's simply invalid mail (equivalent to something sent
>> to a dud address).
>>
> If you want your emails to have the best chance of arriving your SPF should
> list servers you use but not deny that there might be others.

That usually makes the SPF record completely useless. The whole point
is to say that random addresses on the internet _will not_ send mail
from you.

> I have a very common situation where an overly strict SPF may cause
> problems:
>
> Like many people I have multiple email addresses which all end up in the
> same inbox. The one I most commonly give out to businesses bounces the
> email unchanged to the gmail inbox that I use. That means all emails I
> receive through that email address appear to Google to have originated from
> the forwarding servers. An SPF record from the original sender that claims
> to have a complete list of originating servers will therefore fail
> validation.

Ah, there's a solution to this one. You simply use your own
envelope-from address; SPF shouldn't be being checked for the From:
header. Forwarding and using the original sender's address in the SMTP
'MAIL FROM' command is forging mail from them, so it is correct for
that to be thrown out. The mail is coming from your own account, so
you put your address in it, and you might even be able to put an
uber-strict SPF record like "v=spf1 ip4:1.2.3.4 -all" which is quick
to process and guarantees that nobody can pretend to forward mail on
your behalf. The checks are for the *current connection*, not anything
earlier.

ChrisA