Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51013 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-21 16:42 +0200
    Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-22 00:48 +1000
      Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-21 18:19 +0200
        Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-21 11:46 -0600
          Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-21 22:34 +0200
            Re: Simple Python script as SMTP server for outgoing e-mails? Ivan Shmakov <oneingray@gmail.com> - 2013-07-21 20:53 +0000
            Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-21 18:28 -0600
              Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-22 14:11 +0200
                Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-22 22:29 +1000
                  Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-22 14:38 +0200
                    Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-22 22:51 +1000
                    Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-22 08:08 -0600
                    Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-23 00:15 +1000
                      Re: Simple Python script as SMTP server for outgoing e-mails? Duncan Booth <duncan.booth@invalid.invalid> - 2013-07-23 08:06 +0000
                        Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-23 19:19 +1000
                          Re: Simple Python script as SMTP server for outgoing e-mails? Duncan Booth <duncan.booth@invalid.invalid> - 2013-07-23 10:06 +0000
                            Strange behaviour with os.linesep Vincent Vande Vyvre <vincent.vandevyvre@swing.be> - 2013-07-23 13:42 +0200
                              Re: Strange behaviour with os.linesep Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-23 15:25 +0000
                                Re: Strange behaviour with os.linesep Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-23 19:41 -0400
                                Re: Strange behaviour with os.linesep Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-23 19:51 -0400
                                Re: Strange behaviour with os.linesep Vincent Vande Vyvre <vincent.vandevyvre@swing.be> - 2013-07-24 09:02 +0200
                                Re: Strange behaviour with os.linesep Chris Angelico <rosuav@gmail.com> - 2013-07-24 17:39 +1000
                                Re: Strange behaviour with os.linesep Terry Reedy <tjreedy@udel.edu> - 2013-07-24 12:01 -0400
                            Re: Strange behaviour with os.linesep Jason Swails <jason.swails@gmail.com> - 2013-07-23 08:39 -0400
                            Re: Strange behaviour with os.linesep Vincent Vande Vyvre <vincent.vandevyvre@swing.be> - 2013-07-23 15:10 +0200
                            Re: Strange behaviour with os.linesep Vincent Vande Vyvre <vincent.vandevyvre@swing.be> - 2013-07-23 15:26 +0200
                            Re: Strange behaviour with os.linesep Jason Swails <jason.swails@gmail.com> - 2013-07-23 09:35 -0400
                            Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-24 07:37 +1000
                        Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-23 19:30 +1000
                        [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-23 09:12 -0600
                        Re: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-24 07:47 +1000
                        non sequitur: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-23 19:59 -0400
                          Re: non sequitur: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-24 01:42 +0000
                        Re: Simple Python script as SMTP server for outgoing e-mails? Sanjay Arora <sanjay.k.arora@gmail.com> - 2013-08-05 18:43 +0530
                    Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-22 10:25 -0600
                    Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-23 02:32 +1000
                Re: Simple Python script as SMTP server for outgoing e-mails? "Eric S. Johansson" <esj@harvee.org> - 2013-07-22 08:54 -0400
                  Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-23 23:48 +0200
                Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-22 08:10 -0600
                  Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-23 23:50 +0200
    Re: Simple Python script as SMTP server for outgoing e-mails? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-07-21 12:39 -0400
    Re: Simple Python script as SMTP server for outgoing e-mails? Grant Edwards <invalid@invalid.invalid> - 2013-07-21 21:01 +0000
      Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-22 14:13 +0200
      Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-22 14:19 +0200
        Re: Simple Python script as SMTP server for outgoing e-mails? Grant Edwards <invalid@invalid.invalid> - 2013-07-22 14:10 +0000
        Re: Simple Python script as SMTP server for outgoing e-mails? Michael Torrie <torriem@gmail.com> - 2013-07-22 08:21 -0600
        Re: Simple Python script as SMTP server for outgoing e-mails? Chris Angelico <rosuav@gmail.com> - 2013-07-23 02:12 +1000
        Re: Simple Python script as SMTP server for outgoing e-mails? Nobody <nobody@nowhere.com> - 2013-07-22 21:32 +0100
    Re: Simple Python script as SMTP server for outgoing e-mails? Kevin Walzer <kw@codebykevin.com> - 2013-07-22 10:14 -0400
      Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-07-23 23:53 +0200
        Re: Simple Python script as SMTP server for outgoing e-mails? Kevin Walzer <kw@codebykevin.com> - 2013-07-24 10:38 -0400
          Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-08-01 16:15 +0200
            Re: Simple Python script as SMTP server for outgoing e-mails? Wayne Werner <wayne@waynewerner.com> - 2013-08-03 06:47 -0500
              Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-08-06 12:44 +0200
            Re: Simple Python script as SMTP server for outgoing e-mails? Kevin Walzer <kw@codebykevin.com> - 2013-08-03 21:41 -0400
              Re: Simple Python script as SMTP server for outgoing e-mails? Gilles <nospam@nospam.com> - 2013-08-06 12:45 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#51120 — Re: Strange behaviour with os.linesep

Le 23/07/2013 17:25, Steven D'Aprano a écrit :
> On Tue, 23 Jul 2013 13:42:13 +0200, Vincent Vande Vyvre wrote:
>
>> On Windows a script where de endline are the system line sep, the files
>> are open with a double line in Eric4, Notepad++ or Gedit but they are
>> correctly displayed in the MS Bloc-Notes.
> I suspect the problem lies with Eric4, Notepad++ and Gedit. Do you
> perhaps have to manually tell them that the file uses Windows line
> separators?
>
> I recommend opening the file in a hex editor and seeing for yourself what
> line separators are used.
>
>
>> Example with this code:
>> ----------------------------------------------
>> # -*- coding: utf-8 -*-
>>
>> import os
>> L_SEP = os.linesep
>>
>> def write():
>>       strings = ['# -*- coding: utf-8 -*-\n',
>>                   'import os\n',
>>                   'import sys\n']
>>       with open('writetest.py', 'w') as outf:
>>           for s in strings:
>>               outf.write(s.replace('\n', L_SEP))
>>
>> write()
>> ----------------------------------------------
>>
>> The syntax `s.replace('\n', L_SEP)`is required for portability.
> I don't think it is. Behaviour is a little different between Python 2 and
> 3, but by default, Python uses "Universal Newlines". When you open a file
> in text mode, arbitrary line separators should be automatically
> translated to \n when reading, and \n will be automatically translated to
> os.line_sep when writing.
>
>
> http://docs.python.org/3/library/functions.html#open
> http://docs.python.org/2/library/functions.html#open
>
> Some further discussion here:
>
> http://stackoverflow.com/questions/12193047/is-universal-newlines-mode-
> supposed-to-be-default-behaviour-for-open-in-python
>
>
>
In fact, in my code, the original file is open in binary mode, the line 
separator is translate to \n and it is parsed by the module tokenise.

I'm not a Windows user but my code must be run also on Win, this is the 
reason of the usage of os.linesep in writting.

So, now I found the solution, just write the file in binary mode and now 
it is correctly open with all the editors.

Thanks all

-- 
Vincent V.V.
Oqapy <https://launchpad.net/oqapy> . Qarte 
<https://launchpad.net/qarte> . PaQager <https://launchpad.net/paqager>

[toc] | [prev] | [next] | [standalone]

#51121 — Re: Strange behaviour with os.linesep

On Wed, Jul 24, 2013 at 5:02 PM, Vincent Vande Vyvre
<vincent.vandevyvre@swing.be> wrote:
> In fact, in my code, the original file is open in binary mode, the line
> separator is translate to \n and it is parsed by the module tokenise.
>
> I'm not a Windows user but my code must be run also on Win, this is the
> reason of the usage of os.linesep in writting.
>
> So, now I found the solution, just write the file in binary mode and now it
> is correctly open with all the editors.
>

Sounds to me like the problem was double-translation - you in your
code turned \n into \r\n, but then the file was written in text mode,
doing the same translation, so your lines were terminated with \r\r\n.
That would result in what you're seeing (including the oddity that
some editors will show the file differently).

You may find it easier to write the file in text mode and let the
underlying system do the translation for you. Chances are that'll be
correct.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51145 — Re: Strange behaviour with os.linesep

On 7/23/2013 7:41 PM, Dennis Lee Bieber wrote:
> On 23 Jul 2013 15:25:12 GMT, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> declaimed the following:
>
>> On Tue, 23 Jul 2013 13:42:13 +0200, Vincent Vande Vyvre wrote:
>>
>>> On Windows a script where de endline are the system line sep, the files
>>> are open with a double line in Eric4, Notepad++ or Gedit but they are
>>> correctly displayed in the MS Bloc-Notes.
>>
>> I suspect the problem lies with Eric4, Notepad++ and Gedit. Do you
>> perhaps have to manually tell them that the file uses Windows line
>> separators?

I suspect the problem likes in the file written. Notepad++ works fine 
with \r\n or \n on input and can produce either on output.

>  	Don't know about those, but SciTE I know has both an menu option for
> line ending (<cr><lf>, <lf>, <cr>), and one for "convert line endings"



-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#51083 — Re: Strange behaviour with os.linesep

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2013 at 7:42 AM, Vincent Vande Vyvre <
vincent.vandevyvre@swing.be> wrote:

> On Windows a script where de endline are the system line sep, the files
> are open with a double line in Eric4, Notepad++ or Gedit but they are
> correctly displayed in the MS Bloc-Notes.
>
> Example with this code:
> ------------------------------**----------------
> # -*- coding: utf-8 -*-
>
> import os
> L_SEP = os.linesep
>
> def write():
>     strings = ['# -*- coding: utf-8 -*-\n',
>                 'import os\n',
>                 'import sys\n']
>     with open('writetest.py', 'w') as outf:
>         for s in strings:
>             outf.write(s.replace('\n', L_SEP))
>

I must ask why you are setting strings with a newline line ending only to
replace them later with os.linesep.  This seems convoluted compared to
doing something like

def write():
    strings = ['#-*- coding: utf-8 -*-', 'import os', 'import sys']
    with open('writetest.py', 'w') as outf:
        for s in strings:
            outf.write(s)
            outf.write(L_SEP)

Or something equivalent.

If, however, the source strings come from a file you've created somewhere
(and are loaded by reading in that file line by line), then I can see a
problem.  DOS line endings are carriage returns ('\r\n'), whereas standard
UNIX files use just newlines ('\n').  Therefore, if you are using the code:

s.replace('\n', L_SEP)

in Windows, using a Windows-generated file, then what you are likely doing
is converting the string sequence '\r\n' into '\r\r\n', which is not what
you want to do.  I can imagine some text editors interpreting that as two
endlines (since there are 2 \r's).  Indeed, when I execute the code:

>>> l = open('test.txt', 'w')
>>> l.write('This is the first line\r\r\n')
>>> l.write('This is the second\r\r\n')
>>> l.close()

on UNIX and open the resulting file in gedit, it is double-spaced, but if I
just dump it to the screen using 'cat', it is single-spaced.

If you want to make your code a bit more cross-platform, you should strip
out all types of end line characters from the strings before you write
them.  So something like this:

with open('writetest.py', 'w') as outf:
    for s in strings:
        outf.write(s.rstrip('\r\n'))
        outf.write(L_SEP)

Hope this helps,
Jason

[toc] | [prev] | [next] | [standalone]

#51086 — Re: Strange behaviour with os.linesep

Le 23/07/2013 14:39, Jason Swails a écrit :
>
>
>
> On Tue, Jul 23, 2013 at 7:42 AM, Vincent Vande Vyvre 
> <vincent.vandevyvre@swing.be <mailto:vincent.vandevyvre@swing.be>> wrote:
>
>     On Windows a script where de endline are the system line sep, the
>     files are open with a double line in Eric4, Notepad++ or Gedit but
>     they are correctly displayed in the MS Bloc-Notes.
>
>     Example with this code:
>     ----------------------------------------------
>     # -*- coding: utf-8 -*-
>
>     import os
>     L_SEP = os.linesep
>
>     def write():
>         strings = ['# -*- coding: utf-8 -*-\n',
>                     'import os\n',
>                     'import sys\n']
>         with open('writetest.py', 'w') as outf:
>             for s in strings:
>                 outf.write(s.replace('\n', L_SEP))
>
>
> I must ask why you are setting strings with a newline line ending only 
> to replace them later with os.linesep.  This seems convoluted compared 
> to doing something like
>
> def write():
> strings = ['#-*- coding: utf-8 -*-', 'import os', 'import sys']
>     with open('writetest.py', 'w') as outf:
> for s in strings:
>             outf.write(s)
>     outf.write(L_SEP)
>
> Or something equivalent.
>
> If, however, the source strings come from a file you've created 
> somewhere (and are loaded by reading in that file line by line), then 
> I can see a problem.  DOS line endings are carriage returns ('\r\n'), 
> whereas standard UNIX files use just newlines ('\n').  Therefore, if 
> you are using the code:
>
> s.replace('\n', L_SEP)
>
> in Windows, using a Windows-generated file, then what you are likely 
> doing is converting the string sequence '\r\n' into '\r\r\n', which is 
> not what you want to do.  I can imagine some text editors interpreting 
> that as two endlines (since there are 2 \r's).  Indeed, when I execute 
> the code:
>
> >>> l = open('test.txt', 'w')
> >>> l.write('This is the first line\r\r\n')
> >>> l.write('This is the second\r\r\n')
> >>> l.close()
>
> on UNIX and open the resulting file in gedit, it is double-spaced, but 
> if I just dump it to the screen using 'cat', it is single-spaced.
>
> If you want to make your code a bit more cross-platform, you should 
> strip out all types of end line characters from the strings before you 
> write them.  So something like this:
>
> with open('writetest.py', 'w') as outf:
>     for s in strings:
> outf.write(s.rstrip('\r\n'))
>         outf.write(L_SEP)
>
> Hope this helps,
> Jason

The '\n' are in the original file.

I've tested these other versions:

-------------------------------
def write():
     strings = ['# -*- coding: utf-8 -*-\n',
                 'import os\n',
                 'import sys\n']
     with open('writetest.py', 'w') as outf:
         txt = L_SEP.join([s.rstip() for s in strings]):
         outf.write(txt)
------------------------------

-------------------------------
def write():
     strings = ['# -*- coding: utf-8 -*-',
                 'import os',
                 'import sys']
     with open('writetest.py', 'w') as outf:
         txt = L_SEP.join( strings):
         outf.write(txt)
------------------------------

Las, no changes, always correctly displayed in MS bloc-notes but with 
double line in other éditors.

-- 
Vincent V.V.
Oqapy <https://launchpad.net/oqapy> . Qarte 
<https://launchpad.net/qarte> . PaQager <https://launchpad.net/paqager>

[toc] | [prev] | [next] | [standalone]

#51087 — Re: Strange behaviour with os.linesep

Le 23/07/2013 15:10, Vincent Vande Vyvre a écrit :
> The '\n' are in the original file.
>
> I've tested these other versions:
>
> -------------------------------
> def write():
>     strings = ['# -*- coding: utf-8 -*-\n',
>                 'import os\n',
>                 'import sys\n']
>     with open('writetest.py', 'w') as outf:
>         txt = L_SEP.join([s.rstip() for s in strings]):
>         outf.write(txt)
> ------------------------------
>
> -------------------------------
> def write():
>     strings = ['# -*- coding: utf-8 -*-',
>                 'import os',
>                 'import sys']
>     with open('writetest.py', 'w') as outf:
>         txt = L_SEP.join( strings):
>         outf.write(txt)
> ------------------------------
>
> Las, no changes, always correctly displayed in MS bloc-notes but with 
> double line in other éditors.
>

Also with:

----------------------------------------
def count():
     with open('c:\\Users\\Vincent\\writetest.py', 'r') as inf:
         lines = inf.readlines()
     for l in lines:
         print(l, len(l))

count()
--------------------------------------
The output is:

--------------------------------------
('# -*- coding: utf-8 -*-\r\n', 25)
('import os\r\n', 11)
('import sys', 10)

-- 
Vincent V.V.
Oqapy <https://launchpad.net/oqapy> . Qarte 
<https://launchpad.net/qarte> . PaQager <https://launchpad.net/paqager>

[toc] | [prev] | [next] | [standalone]

#51089 — Re: Strange behaviour with os.linesep

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2013 at 9:26 AM, Vincent Vande Vyvre <
vincent.vandevyvre@swing.be> wrote:

> Le 23/07/2013 15:10, Vincent Vande Vyvre a écrit :
>
>  The '\n' are in the original file.
>>
>> I've tested these other versions:
>>
>> ------------------------------**-
>> def write():
>>     strings = ['# -*- coding: utf-8 -*-\n',
>>                 'import os\n',
>>                 'import sys\n']
>>     with open('writetest.py', 'w') as outf:
>>         txt = L_SEP.join([s.rstip() for s in strings]):
>>         outf.write(txt)
>> ------------------------------
>>
>> ------------------------------**-
>> def write():
>>     strings = ['# -*- coding: utf-8 -*-',
>>                 'import os',
>>                 'import sys']
>>     with open('writetest.py', 'w') as outf:
>>         txt = L_SEP.join( strings):
>>         outf.write(txt)
>> ------------------------------
>>
>> Las, no changes, always correctly displayed in MS bloc-notes but with
>> double line in other éditors.
>>
>>
> Also with:
>
> ------------------------------**----------
> def count():
>     with open('c:\\Users\\Vincent\\**writetest.py', 'r') as inf:
>         lines = inf.readlines()
>     for l in lines:
>         print(l, len(l))
>

Unrelated comment, but in general it's (much) more efficient to iterate
through a file rather than iterate through a list of strings generated by
readlines():

def count():
    with open('c:\\Users\\Vincent\\writetest.py', 'r') as inf:
        for l in lines:
            print(l, len(l))

It's also fewer lines of code.

('# -*- coding: utf-8 -*-\r\n', 25)
> ('import os\r\n', 11)
> ('import sys', 10)


Then it seems like there is an issue with your text editors that do not
play nicely with DOS-style line endings.  Gedit on my linux machine
displays the line endings correctly (that is, '\r\n' is rendered as a
single line).

Good luck,
Jason

[toc] | [prev] | [next] | [standalone]

#51099

On Tue, Jul 23, 2013 at 8:06 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Excellent idea, I'll tell the email forwarding service to rewrite their
> system immediately.

Yes. If they are using your domain in the MAIL FROM command and not
using your mail servers, then yes, you should tell them, and use a
different service until they fix that. It is not SPF's fault. It is a
fundamental error of protocol, which SPF checks are highlighting.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51077

On Tue, Jul 23, 2013 at 7:19 PM, Chris Angelico <rosuav@gmail.com> wrote:
> 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.

There's an example, by the way, of this exact technique right here -
python-list@python.org sends mail to me with an envelope-from of
"python-list-bounces+rosuav=gmail.com@python.org" - which passes SPF,
since python.org has a TXT record designating the sending IP as one of
theirs. It doesn't matter that invalid.invalid (your supposed domain)
doesn't have an SPF record, nor would it be a problem if it had one
that said "v=spf1 -all", because that domain wasn't checked. Mailing
lists are doing the same sort of forwarding that you're doing.

(Apologies to those who read this as a newsgroup, for whom this won't
be as parallel an example. But it's still the case, just not for the
posts you receive.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#51090 — [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails?

On 07/23/2013 03:30 AM, Chris Angelico wrote:
> On Tue, Jul 23, 2013 at 7:19 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> 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.
> 
> There's an example, by the way, of this exact technique right here -
> python-list@python.org sends mail to me with an envelope-from of
> "python-list-bounces+rosuav=gmail.com@python.org" - which passes SPF,
> since python.org has a TXT record designating the sending IP as one of
> theirs. It doesn't matter that invalid.invalid (your supposed domain)
> doesn't have an SPF record, nor would it be a problem if it had one
> that said "v=spf1 -all", because that domain wasn't checked. Mailing
> lists are doing the same sort of forwarding that you're doing.

This is good and all, and I think I will modify my local postfix mail
server I use for personal stuff, just for correctness' sake.

I hadn't spent much time studying SPF in depth before, but after reading
your comments (which were insightful) I'm now more convinced that SPF is
worthless than ever, at least as a spam prevention mechanism.  Spammers
can use throwaway domains that publish very non-strict SPF records, and
spam to their hearts content with random forged from addresses and SPF
checks pass.  The only way around that is to enforce SPF on the From:
header in the e-mail itself, which we all agree is broken.  I've been
reading this:

http://www.openspf.org/FAQ/SPF_is_not_about_spam

Not very encouraging.  When the other expensive options for going after
spammers who have valid SPF records, they propose domain blacklists as a
solution.

[toc] | [prev] | [next] | [standalone]

#51100 — Re: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails?

On Wed, Jul 24, 2013 at 1:12 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 07/23/2013 03:30 AM, Chris Angelico wrote:
>> On Tue, Jul 23, 2013 at 7:19 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>> 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.
>>
>> There's an example, by the way, of this exact technique right here -
>> python-list@python.org sends mail to me with an envelope-from of
>> "python-list-bounces+rosuav=gmail.com@python.org" - which passes SPF,
>> since python.org has a TXT record designating the sending IP as one of
>> theirs. It doesn't matter that invalid.invalid (your supposed domain)
>> doesn't have an SPF record, nor would it be a problem if it had one
>> that said "v=spf1 -all", because that domain wasn't checked. Mailing
>> lists are doing the same sort of forwarding that you're doing.
>
> This is good and all, and I think I will modify my local postfix mail
> server I use for personal stuff, just for correctness' sake.

Correctness is a worthwhile reason to do something :)

> I hadn't spent much time studying SPF in depth before, but after reading
> your comments (which were insightful) I'm now more convinced that SPF is
> worthless than ever, at least as a spam prevention mechanism.  Spammers
> can use throwaway domains that publish very non-strict SPF records, and
> spam to their hearts content with random forged from addresses and SPF
> checks pass.  The only way around that is to enforce SPF on the From:
> header in the e-mail itself, which we all agree is broken.  I've been
> reading this:
>
> http://www.openspf.org/FAQ/SPF_is_not_about_spam

There are several things that SPF achieves, but mainly it's a measure
of trust. If you receive email from a domain I run, and the SPF record
permits the IP that sent it to you, you can have a high degree of
confidence that it really is from that domain. Suppose, for instance,
that (pick a bank, any bank) has a strict SPF record. Someone tries to
send a phishing email purporting to be from that bank. They then have
to use a different envelope-from address, which instantly marks the
mail as suspicious to anyone who's checking. But more likely, what
they'll do is simply ignore SPF and send it anyway. That means that
any MTA that checks SPF records is immediately freed of all that bad
mail - which is more than just spam, it's a major vulnerability
(thinking here of corporate networks where all the company's mail goes
through a central server, and then a whole lot of non-technical people
read it). In the same way that banks assure us that they will *never*
ask for your password, they could also assure us that they will
*never* send account information from any other domain.

Spammers look for the easy pickings. If your X million addresses
become (X-1),999,900 because a few servers are rejecting their mail,
what do they care? But those hundred people now haven't seen that
spam. Sure, spammers can easily get around SPF checks... but that
won't get all that likely until the bulk of MTAs start checking. For
now, we can take all the benefit. Later on, the world can look to
other solutions.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51112 — non sequitur: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails?

On Wed, 24 Jul 2013 07:47:28 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>
>Correctness is a worthwhile reason to do something :)

	I've been reading a collection of "Liaden" short stories... and for
some reason that phrasing sounds a lot like the more formal Liaden speech
patterns. {Liaden culture seems heavy on personal honor, and comments tend
(to me) be worded to avoid any chance of being interpreted as disparaging
of the person with whom one is speaking... Hmmm, pity such modes can't be
enforced on the newsgroups <G>}

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#51115 — Re: non sequitur: [OT] SPF - was Re: Simple Python script as SMTP server for outgoing e-mails?

On Tue, 23 Jul 2013 19:59:01 -0400, Dennis Lee Bieber wrote:

> {Liaden culture seems heavy on personal honor, and comments tend (to me)
> be worded to avoid any chance of being interpreted as disparaging of the
> person with whom one is speaking... Hmmm, pity such modes can't be
> enforced on the newsgroups <G>}

Are you implying that failure to avoid disparaging others in newsgroups 
is harmful? That disparages me.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#51957

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 23, 2013 at 2:49 PM, Chris Angelico <rosuav@gmail.com> wrote:


> 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
>

Bit Late, but do check out  http://www.openspf.org/FAQ/Forwarding

Forwarding does get broken, but a partial solution in whitelisting is
there, though too manual & therefore cumbersome.

Another option http://www.openspf.org/SRS is there to be worked in
conjunction with spf. There is a best spf practices guide on the site. And
all this email authentication issue given on openspf.org makes an
interesting read.

Ciao.
Sanjay.

[toc] | [prev] | [next] | [standalone]

#51051

On 07/22/2013 08:15 AM, Chris Angelico wrote:
> 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).

Sure. Tell that to the people you work for who depend on e-mail.  When I
was a sysadmin (quite recently), I'd have gotten fired for enforcing
such an arbitrary policy.  Indeed when mail wasn't coming through that
someone in the organization was expecting and wanting, regardless of
SPF, it was indeed *my* problem and my job was on the line.  BOFH
attitudes simply aren't going to change that reality.

SPF is just one more of the many things that are contributing overall to
absolutely breaking and demise of SMTP.  I'm afraid when it does finally
cease to work, it's going to be replaced with less open,
centrally-controlled messaging systems like facebook.  Which is unfortunate.

[toc] | [prev] | [next] | [standalone]

#51052

On Tue, Jul 23, 2013 at 2:25 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 07/22/2013 08:15 AM, Chris Angelico wrote:
>> 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).
>
> Sure. Tell that to the people you work for who depend on e-mail.  When I
> was a sysadmin (quite recently), I'd have gotten fired for enforcing
> such an arbitrary policy.  Indeed when mail wasn't coming through that
> someone in the organization was expecting and wanting, regardless of
> SPF, it was indeed *my* problem and my job was on the line.  BOFH
> attitudes simply aren't going to change that reality.

Is your job on the line if the sender of that email got the
recipient's address right? Is your job on the line if the sender
mucked up his SMTP settings and the message didn't even get to your
server? Is your job on the line if the email never even got sent? Then
why should your job be on the line if the sender violates his own
declared protocol? Remember, if you don't publish an SPF record, your
emails will be accepted regardless. It's only if you explicitly create
that DNS record that ends with "-all" that any of this will happen -
which means you *asked* for that mail to be rejected. If you do that
and then send mail from a different IP, then I *will* reject it.
Accepting mail and just giving it a spam score is *worse*, because the
sender won't even know why it didn't get through (what if most of his
mail gets accepted, but that one email when he sent a blank body,
subject "RE: your invoice", and a zip file attachment, managed to trip
the spam cutoff and get dumped?), whereas rejecting will result in a
quick and easy bounce, probably within seconds (minutes maybe).

I stand by SPF checking. It has never been a problem. If you don't
stand by protocols, you weaken those protocols.

And speaking of protocols, I'm now going to have to follow the "I'm on
an airliner and mobile phones have to be turned off" protocol, as the
flight's due to depart shortly. Ah, protocols... some you love, some
not so much.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51038

On Mon, 22 Jul 2013 08:11:25 -0400, Gilles <nospam@nospam.com> wrote:

> On Sun, 21 Jul 2013 18:28:27 -0600, Michael Torrie <torriem@gmail.com>
> wrote:
>> The Sendmail MTA has been ported to many platforms including windows.
>> But...
>
> Thanks for the tip. Since I couldn't find a good, basic, native
> Windows app, I was indeed about to look at eg. Exim + Cygwin, and
> resort to a Linux appliance if none footed the bill.
>


try http://emailrelay.sourceforge.net/

[toc] | [prev] | [next] | [standalone]

#51101

On Mon, 22 Jul 2013 08:54:11 -0400, "Eric S. Johansson"
<esj@harvee.org> wrote:
>try http://emailrelay.sourceforge.net/

Thanks. I did find it, but it says it's not a full MTA:

"E-MailRelay is not a routing MTA. It forwards e-mail to a
pre-configured SMTP server, regardless of any message addressing or
DNS redirects."
http://emailrelay.sourceforge.net/userguide.html#SH_1_2

IOW, it'll just send outbound e-mails to my ISP's MTA, so I'm back at
square one.

[toc] | [prev] | [next] | [standalone]

#51043

On 07/22/2013 06:11 AM, Gilles wrote:
> On Sun, 21 Jul 2013 18:28:27 -0600, Michael Torrie <torriem@gmail.com>
> wrote:
>> The Sendmail MTA has been ported to many platforms including windows.
>> But...
> 
> Thanks for the tip. Since I couldn't find a good, basic, native
> Windows app, I was indeed about to look at eg. Exim + Cygwin, and
> resort to a Linux appliance if none footed the bill.

Where did you look?  Here's one I found.  It's not the real sendmail
program, but it implements the interface which is all you need:

http://glob.com.au/sendmail/

I just googled for sendmail win32

[toc] | [prev] | [next] | [standalone]

#51102

On Mon, 22 Jul 2013 08:10:10 -0600, Michael Torrie <torriem@gmail.com>
wrote:
>Where did you look?  Here's one I found.  It's not the real sendmail
>program, but it implements the interface which is all you need:
>
>http://glob.com.au/sendmail/
>
>I just googled for sendmail win32

Thanks, but I need an MTA, not just a command-line app, so I can send
e-mails from my e-mail client and just change the SMTP line in the
configuration.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web