Question about smtplib, and mail servers in general.

Steve Holden steve at
Wed Sep 21 08:50:26 CEST 2005

Peter Hansen wrote:
> Steve Holden wrote:
>>Peter Hansen wrote:
>>>In any case, unless the mail server will allow "relaying", which most 
>>>don't these days (to prevent spamming), then it won't work the way you 
>>>are hoping unless *all* the 100 addresses are local ones, to be 
>>>delivered to users on the server you are sending the mail to.
>>>If the addresses are scattered all over the planet, and the server 
>>>allows relaying, then it's intended for exactly this sort of use 
>>>(other than if it's spam ;-) ), and no, you won't be putting a "drain" 
>>>on the server.
>>To add one final note, if the "fromaddress" belongs to a domain that's 
>>properly handled by the SMTP server then you aren't relaying (since you 
>>are a legitimate domain user) so the mails should go through.
> I think that statement might not be widely valid any more, Steve.  In my 
> experience, lately, many if not most servers pay no attention to the 
> "MAIL FROM" address but instead allow relaying only from *IP addresses* 
> on the "internal" network (e.g. those served by an ISP, for example), 
> regardless of how the sender is identified.  On a Linux box with Qmail, 
> for example, one would have an /etc/tcp.smtp file which specifies for 
> which subnets relaying is allowed, and all others are disallowed 
> regardless of the claimed MAIL FROM address.
> It's kind of a shame, really, that you can no longer trust either the 
> recipient *or* the sender addresses when using basic SMTP.  Damn spammers.
I agree that there's an element of the moral imperative in my assertion 
that the mails "should" go through which is largely ignored by the real 
world nowadays. Some ISPs force you to use their SMTP servers no matter 
what the sending domain, which is rather annoying when you travel a lot. 
I end up having to vary my default SMTP server as I move.

Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC           
PyCon TX 2006                

More information about the Python-list mailing list