Re: Chrooting smtp (non-d) client activity for resolv.conf segregation

[Geert Hendrickx]

On Wed, Dec 03, 2008 at 09:59:17PM -0500, brian dodds wrote:
> On Wed, Dec 3, 2008 at 8:25 PM, Wietse Venema <[EMAIL PROTECTED]> wrote:
> >
> > Some third-party library is calling stuff before Postfix chroots.
> >
> > Postfix does not support chroot environments that are out of sync
> > with the host environment; I am not going to jump hoops to make
> > that possible.
> >
> > If you want Postfix to use a different resolver, use main.cf's
> > export_environment parameter to override resolver settings if
> > possible, run the whole lot in a FreeBSD jail, in a Solaris zone,
> > or in a Linux virtual server partition.
> 
> I wasn't looking for hoop jumping, just further insight, which you've
> provided.  I guess I'd interpreted all of the chroot documentation
> slightly incorrectly - wherever it says to include necessary files, at
> the very least /etc/hosts and /etc/resolv.conf, I insinuated that they
> would definitely be used.  In actuality it's because they might be
> used, and in some cases in a version of *nix that behaved differently
> (probably BSD) they were necessary - in my current linux incarnation,
> not so much.
> 
> Thanks for the heads up on the export_environment idea, I'll pursue
> that before virtualizing the entire application.



What exactly are you trying to achieve?  If you want to modify delivery
for just a couple of domains, you can use a transport(5) table.

http://www.postfix.org/transport.5.html


Geert

Re: SBC Global

[Bill Light]

James D. Parra wrote:

SBCGlobal does not block ingress port 25 to their mailservers.

They block egress 25 from their residential networks.
~

BDA is correct. That is what I meant.

Sorry for the confusion.

~James
  
Don't shoot the messenger, but 64.22.79.211 is on 11 different 
(fiveten...) blacklists.  And, I personally have lots of trouble with 
Global Net Access which seems to host more than its share of spam 
houses.  My local blacklist is blocking the /24 subnet.


Take a look at   http://www.mxtoolbox.com/blacklists.aspx

Bill

Re: Chrooting smtp (non-d) client activity for resolv.conf segregation

[brian dodds]

On Wed, Dec 3, 2008 at 8:25 PM, Wietse Venema <[EMAIL PROTECTED]> wrote:
>
> Some third-party library is calling stuff before Postfix chroots.
>
> Postfix does not support chroot environments that are out of sync
> with the host environment; I am not going to jump hoops to make
> that possible.
>
> If you want Postfix to use a different resolver, use main.cf's
> export_environment parameter to override resolver settings if
> possible, run the whole lot in a FreeBSD jail, in a Solaris zone,
> or in a Linux virtual server partition.

I wasn't looking for hoop jumping, just further insight, which you've
provided.  I guess I'd interpreted all of the chroot documentation
slightly incorrectly - wherever it says to include necessary files, at
the very least /etc/hosts and /etc/resolv.conf, I insinuated that they
would definitely be used.  In actuality it's because they might be
used, and in some cases in a version of *nix that behaved differently
(probably BSD) they were necessary - in my current linux incarnation,
not so much.

Thanks for the heads up on the export_environment idea, I'll pursue
that before virtualizing the entire application.

thanks!

b

Re: Visibility of Postfix docs, (was: Testing SASL HOWTO using telnet/Postfix/dovecot?)

[M. Fioretti]

On Thu, Dec 04, 2008 01:45:35 AM +0100, mouss wrote:

> not sure I undertsand what you have in mind. but lessee.
... see the archives if really interested.

Now, answering to this:

> was this really long? difficult?

and to the comment along similar lines from Wietse:

> Next time, try the SEARCH field on the Postfix home page. It's been
> there for at least five years.

First, I didn't say that when I experienced this "search visibility
problem" myself it was with SASL, I just remember vaguely that I had
already signalled such a problem. Second, it's not a "next time"
problem, it's a "first time" problem. To me it doesn't happen anymore,
or very seldom. We were speaking of newcomers.

Third, and most important: things are not difficult or long only *if*
you already know exactly where to look for and what are the right
terms to look for. My first or almost first message to this list was
more or less like "I have no problem to study manuals and man pages
myself, but I need to understand *what* are the right docs to read to
do what I want to do: just because email terminology is damn confusing
even if I'm far from a novice Linux user"

Fourth: the "search box" at postfix.org is just a google search
restricted to postfix.org. But the docs at postfix.org are very
thorough, focused technical documentation explaining every single bit
and variable of the program. Take this as a compliment, because that's
what it is. But, exactly because of this and of the "third thing"
above, one quickly learns that searching directly via Google *without*
site restrictions is *better*, as in "more efficient" than the
postfix.org search box.

Because, very often, it returns at least one or two task-focused
tutorials, pages from http://postfix.state-of-mind.de/patrick.koetter
or single messages from this very list which explain what to write in
main.cf or master.cf to do what you needed.

Please remind that NONE of this is meant to dismiss your great work,
NOR to request that anybody does anything. It's just a possible
explanation of why one should not be surprised if certain requests
keep popping up even if to the veterans the subject seemed very simple
to find.

Good night,
Marco
-- 
Your own civil rights and the quality of your life heavily depend on how
software is used *around* you:http://digifreedom.net/node/84

Re: Chrooting smtp (non-d) client activity for resolv.conf segregation

[Wietse Venema]

brian dodds:
[ Charset ISO-8859-1 unsupported, converting... ]
> So I've done a bit of reading on postfix's internal chrooting
> capabilities and I thought it would fit exactly what I'm trying to do
> perfectly.  Here is the simple desired functionality:
> 
> .  I want outbound email name lookups to use a different set of name
> servers than what the system normally uses in literal /etc/resolv.conf
> 
> To accomplish this, I set the smtp service to chroot in master.cf and
> I moved the resolv libraries into /var/spool/postfix/lib and created a
> /var/spool/postfix/etc/resolv.conf with the nameservers i wanted to
> use.  I'm running Postfix 2.3.3 on CentOS 5.2 (2.6.24) with SELinux.
> I added the chroot capability for the smtp binary to my SELinux
> policy.  Postfix starts uneventfully, save for the warning about
> mismatched resolv.conf files, which is what I expect (in fact, is what
> I want).  This is what I'm now seeing when I send mail:
> 
> .  smtpd runs, accepts the mail (opens literal /etc/resolv.conf vs.
> chroot /etc/resolv.conf and reads that)
> .  proxymap runs next, opens literal /etc/resolv.conf
> .  trivial-rewrite comes next, same resolv.conf
> .  cleanup runs, same resolv.conf
> .  smtp runs, establishes environment, opens literal /etc/resolv.conf
> - not chroot /etc/resolv.conf, reads contents, *then chroots*, then
> performs DNS lookups using the wrong DNS servers
> 
> Why does the chroot happen after the name resolution environment is
> established?  Wouldn't that mean that having the /etc/resolv.conf in
> the chroot is unnecessary? And more importantly, how can I get smtp
> outbound to read a different resolv.conf for me?

Some third-party library is calling stuff before Postfix chroots.

Postfix does not support chroot environments that are out of sync
with the host environment; I am not going to jump hoops to make
that possible. 

If you want Postfix to use a different resolver, use main.cf's
export_environment parameter to override resolver settings if
possible, run the whole lot in a FreeBSD jail, in a Solaris zone,
or in a Linux virtual server partition.

Wietse

Chrooting smtp (non-d) client activity for resolv.conf segregation

[brian dodds]

So I've done a bit of reading on postfix's internal chrooting
capabilities and I thought it would fit exactly what I'm trying to do
perfectly.  Here is the simple desired functionality:

.  I want outbound email name lookups to use a different set of name
servers than what the system normally uses in literal /etc/resolv.conf

To accomplish this, I set the smtp service to chroot in master.cf and
I moved the resolv libraries into /var/spool/postfix/lib and created a
/var/spool/postfix/etc/resolv.conf with the nameservers i wanted to
use.  I'm running Postfix 2.3.3 on CentOS 5.2 (2.6.24) with SELinux.
I added the chroot capability for the smtp binary to my SELinux
policy.  Postfix starts uneventfully, save for the warning about
mismatched resolv.conf files, which is what I expect (in fact, is what
I want).  This is what I'm now seeing when I send mail:

.  smtpd runs, accepts the mail (opens literal /etc/resolv.conf vs.
chroot /etc/resolv.conf and reads that)
.  proxymap runs next, opens literal /etc/resolv.conf
.  trivial-rewrite comes next, same resolv.conf
.  cleanup runs, same resolv.conf
.  smtp runs, establishes environment, opens literal /etc/resolv.conf
- not chroot /etc/resolv.conf, reads contents, *then chroots*, then
performs DNS lookups using the wrong DNS servers

Why does the chroot happen after the name resolution environment is
established?  Wouldn't that mean that having the /etc/resolv.conf in
the chroot is unnecessary? And more importantly, how can I get smtp
outbound to read a different resolv.conf for me?

Many thanks,

b

RE: SBC Global

[James D. Parra]

SBCGlobal does not block ingress port 25 to their mailservers.

They block egress 25 from their residential networks.
~

BDA is correct. That is what I meant.

Sorry for the confusion.

~James

Re: Visibility of Postfix docs, (was: Testing SASL HOWTO using telnet/Postfix/dovecot?)

[mouss]

M. Fioretti a écrit :
> On Thu, Dec 04, 2008 00:02:33 AM +0100, mouss wrote:
>> Roderick A. Anderson a écrit :
>>> Magnus Bäck wrote:
 [snip]
 Why do you insist on testing this with telnet?...
>>> Because I can do it one step at a time and see the results that
>>> Postfix sends back.  I hadn't thought of telnet possibly munging
>>> base64 encoded values.  They looked like ASCII-only to me.
>> well, you said you tried google and possibly other things. but did
>>  you try http://www.postfix.org/SASL_README.html#server_test
>> ...
> 
> Sorry to step in, but I already pointed out one year ago or so that
> there is a problem with answers like these. In the results of many
> Postfix-related searches, especially those a newbye may make, the
> official postfix.org pages often are _far_ from being the first
> result: before them you get a screenful or so of links to howtos which
> (seem to) "just work", so you never get to the postfix pages, nor feel
> any need to get there. I posted specific examples of this here last year.
> 
> That's why there are, several times a year, cases like the one above:
> for some reason that, sorry, I'm unable to help with, the official
> documentation is quite SEU (Search Engine Unoptimized). Don't ask me
> why, but that's what happens.
> 

not sure I undertsand what you have in mind. but lessee.

Firs of all, since you use postfix, the first place to look for is the
postfix site, and you should quickly find
http://www.postfix.org/documentation.html

but let's say you prefer to use google because you like search engines.
I don't know for you, but here is what I do:

1- I load www.google.com and I type: postfix sasl test
2- I click on the first returned link
3- I am on the postfix sasl page.
4- I use CTRL-F to look for "test"
5- I click on the link. which is exactly the one I sent you.

was this really long? difficult?

Re: Visibility of Postfix docs, was: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Wietse Venema]

M. Fioretti:
> On Thu, Dec 04, 2008 00:02:33 AM +0100, mouss wrote:
> > Roderick A. Anderson a ?crit :
> > > Magnus B?ck wrote:
> > >> [snip]
> > >> Why do you insist on testing this with telnet?...
> > > 
> > > Because I can do it one step at a time and see the results that
> > > Postfix sends back.  I hadn't thought of telnet possibly munging
> > > base64 encoded values.  They looked like ASCII-only to me.
> > 
> > well, you said you tried google and possibly other things. but did
> > you try http://www.postfix.org/SASL_README.html#server_test
> > ...
> 
> Sorry to step in, but I already pointed out one year ago or so that
> there is a problem with answers like these. In the results of many
> Postfix-related searches, especially those a newbye may make, the
> official postfix.org pages often are _far_ from being the first
> result: before them you get a screenful or so of links to howtos which
> (seem to) "just work", so you never get to the postfix pages, nor feel
> any need to get there. I posted specific examples of this here last year.
> 
> That's why there are, several times a year, cases like the one above:
> for some reason that, sorry, I'm unable to help with, the official
> documentation is quite SEU (Search Engine Unoptimized). Don't ask me
> why, but that's what happens.

Next time, try the SEARCH field on the Postfix home page.
It's been there for at least five years.

Wietse

Re: Visibility of Postfix docs, was: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Victor Duchovni]

On Thu, Dec 04, 2008 at 01:19:57AM +0100, M. Fioretti wrote:

> On Thu, Dec 04, 2008 00:02:33 AM +0100, mouss wrote:
> > Roderick A. Anderson a ?crit :
> > > Magnus B?ck wrote:
> > >> [snip]
> > >> Why do you insist on testing this with telnet?...
> > > 
> > > Because I can do it one step at a time and see the results that
> > > Postfix sends back.  I hadn't thought of telnet possibly munging
> > > base64 encoded values.  They looked like ASCII-only to me.
> > 
> > well, you said you tried google and possibly other things. but did
> > you try http://www.postfix.org/SASL_README.html#server_test
> > ...
> 
> Sorry to step in, but I already pointed out one year ago or so that
> there is a problem with answers like these. In the results of many
> Postfix-related searches, especially those a newbye may make, the
> official postfix.org pages often are _far_ from being the first
> result: before them you get a screenful or so of links to howtos which
> (seem to) "just work", so you never get to the postfix pages, nor feel
> any need to get there. I posted specific examples of this here last year.
> 
> That's why there are, several times a year, cases like the one above:
> for some reason that, sorry, I'm unable to help with, the official
> documentation is quite SEU (Search Engine Unoptimized). Don't ask me
> why, but that's what happens.

I guess there are more links to the how-to's than to the official docs.
It would help if how-tos always linked back to the docs that provide
further info on the subject the how-tos cover.

This said the first Google hit for "Postfix TLS" is the official TLS_README,
so the official docs don't lose all the time. Likewise with "Postfix SASL".

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Visibility of Postfix docs, was: Testing SASL HOWTO using telnet/Postfix/dovecot?

[M. Fioretti]

On Thu, Dec 04, 2008 00:02:33 AM +0100, mouss wrote:
> Roderick A. Anderson a écrit :
> > Magnus Bäck wrote:
> >> [snip]
> >> Why do you insist on testing this with telnet?...
> > 
> > Because I can do it one step at a time and see the results that
> > Postfix sends back.  I hadn't thought of telnet possibly munging
> > base64 encoded values.  They looked like ASCII-only to me.
> 
> well, you said you tried google and possibly other things. but did
>   you try http://www.postfix.org/SASL_README.html#server_test
> ...

Sorry to step in, but I already pointed out one year ago or so that
there is a problem with answers like these. In the results of many
Postfix-related searches, especially those a newbye may make, the
official postfix.org pages often are _far_ from being the first
result: before them you get a screenful or so of links to howtos which
(seem to) "just work", so you never get to the postfix pages, nor feel
any need to get there. I posted specific examples of this here last year.

That's why there are, several times a year, cases like the one above:
for some reason that, sorry, I'm unable to help with, the official
documentation is quite SEU (Search Engine Unoptimized). Don't ask me
why, but that's what happens.

HTH,
Marco
-- 
Your own civil rights and the quality of your life heavily depend on how
software is used *around* you:http://digifreedom.net/node/84

Re: DKIM message forwarding, body altered

[John Capo]

Quoting David Jonas ([EMAIL PROTECTED]):
> We provide forwarding to external accounts (e.g. gmail.com) and it
> appears that in some cases postfix is invalidating the DKIM signatures.
> The most prominent and obvious case is eBay and PayPal where gmail is
> now bouncing/dropping messages where the signature doesn't match.
> 
> I caused ebay to send an email to a gmail address and then to an address
> that forwards. Doing a diff between the messages show this:
> 
> # diff -u ebay-fail.txt ebay-pass.txt
> ...
> @@ -92,6 +83,7 @@
>  Designated trademarks and brands are the property of their respective
> owner=
>  s.
>  eBay and the eBay logo are registered trademarks or trademarks of eBay,
> Inc=
> -=20
> +.=20
>  eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125.
> 
> Adding a "." to that line in the version that doesn't verify causes the
> message to verify.
> 
> Is there something I can do to keep postfix from altering this?  Am I
> barking up the right tree, or should I be verifying these and resigning
> them? Should I just tell my customers, "tough luck, use your gmail
> account directly?"
> 
> Any help is appreciated.

Not body related but Paypal includes headers in the DKIM header
specification that do not exist when they originate the message,
but some of those headers may be added when a message is forwarded.
 
 h=from:sender:reply-to:subject:date:message-id:to:cc:
mime-version:content-transfer-encoding:content-id:
content-description:resent-date:resent-from:resent-sender:
resent-to:resent-cc:resent-message-id:in-reply-to:
references:list-id:list-help:list-unsubscribe:
list-subscribe:list-post:list-owner:list-archive;

We add a Resent-From: header to forwarded mail to satisfy Hotmail's
SenderID crap.  That additional header causes the signature check
to fail at Gmail.  Yet another policy daemon that only prepends a
Resent-From: header for Hotmail would be a solution but I'm quite
tired of fixing problems created by others.

John Capo

Re: Avoiding (trivial) spoofed "mail from"

[mouss]

DJ Lucas a écrit :
> LuKreme wrote:
>> On 2-Dec-2008, at 20:21, DJ Lucas wrote:
>>> I can find absolutely no reason to inadvertently mislead, or worse,
>>> intentionally deceive the recipient by forging the envelope sender's
>>> address.  In fact, the only reason I can see, is
>>> to intentionally deceive the recipient.  Is there any other reason?
>> Sure there is.  
> 
> No there isn't. 

Yes. there is;-p can we agree to disagree or do we need to contact the UNO?

> AFAIK, unless I'm misunderstanding something, the rest
> of your message simply puts what I said above in different terms and
> agrees entirely.  **my mom** was in the From header...nowhere else.  
> The From header can be changed up to say that it came from somebody
> else.  I don't care about that.  The check in question is in the smtp
> transaction, not the data.
> 
> -- DJ Lucas
> 
> 

Re: DKIM message forwarding, body altered

[Victor Duchovni]

On Wed, Dec 03, 2008 at 01:49:49PM -0800, David Jonas wrote:

> > If they do it correctly, perhaps you have content filters or down-stream
> > SMTP senders that are broken. What software other than Postfix do
> > the messages traverse before forwarding?
> >

> I found the culprit.
> 
> To get an X-Original-To header on the forwarded emails they get run
> through pipe and back to postfix with smtpclient
> (http://www.freebsdsoftware.org/mail/smtpclient.html):
> 
> xorig unix  -   n   n   -   -  pipe
>   flags=Ohuq user=smtpclient argv=/usr/bin/smtpclient
>   -w -S 127.0.0.1 -P 4525 -f ${sender} -- ${recipient}

The main problem is that you can't preserve SMTP error reporting
semantics with multiple recipients, as pipe(8) deliveries either
succeed for all recipients or fail for all, so you have to set
"xorig_destination_recipient_limit = 1". This is not a win, but
at low volumes, you can get away with it by adding the "." flag:

xorig unix  -   n   n   -   -  pipe
flags=.Ohuq user=smtpclient argv=/usr/bin/smtpclient
-w -S 127.0.0.1 -P 4525 -f ${sender} -- ${recipient}

> We also use smtpclient to pass the messages back from spamc to a special
> port.
> 
> A quick test showed that smtpclient was stripping that dot. I sincerely
> apologize for the noise, but I did learn a lot here. Thanks for the help.
> 
> Any other options besides smtpclient to pass the message back to a
> different port? This is already a multi-instance setup, one for regular
> incoming mail/backup mx'ing and another for filtering the local and
> forwarding mail.

A policy service can prepend a header.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: SBC Global

[mouss]

Greg Coates a écrit :
> OK.  My IP is 64.22.79.211
> 


$ host 64.22.79.211
211.79.22.64.in-addr.arpa domain name pointer coatesoft.com.
$ host 64.22.79.212
212.79.22.64.in-addr.arpa domain name pointer datingfreely.com.
$ host 64.22.79.213
213.79.22.64.in-addr.arpa domain name pointer freetoswing.com.
$ host 64.22.79.214
214.79.22.64.in-addr.arpa domain name pointer signal-9.com.
$ host 64.22.79.215
215.79.22.64.in-addr.arpa domain name pointer irc.christian-planet.com.
$ host 64.22.79.216
216.79.22.64.in-addr.arpa domain name pointer lostntranslation.com.
$ host 64.22.79.217
217.79.22.64.in-addr.arpa domain name pointer davr.org.
$ host 64.22.79.218
Host 218.79.22.64.in-addr.arpa. not found: 3(NXDOMAIN)
$ host 64.22.79.210
210.79.22.64.in-addr.arpa domain name pointer davejmurphy.com.
$ host 64.22.79.208
208.79.22.64.in-addr.arpa domain name pointer ahmadsoft.org.

did you get infos about these people around you? (check rdns, check
whois, ...). maybe one of them has spammed sbcglobal...

or maybe sbcglobal don't like your hoster

http://www.rfc-ignorant.org/tools/lookup.php?domain=gnax.net

Re: SBC Global

[J.P. Trosclair]

Greg Coates wrote:

OK.  My IP is 64.22.79.211

Greg



I see no obvious problems with your DNS. I also have no problem 
connecting to sbcmx3.prodigy.net (from your logs) on port 25 from our 
network. Here the host resolves to the same IP address as listed in your 
logs as well. It may be time to try and get in touch with their support.


J.P.

Re: SBC Global

[Greg Coates]

OK.  My IP is 64.22.79.211

Greg

mouss wrote:

Greg Coates a écrit :

Of course.  I can't believe I didn't think of that.

Is there any way to get postfix to _send_ using port 587 for certain
domains?



587 is for submission, not for MX. if you have an account at an ISP, you
can use 587 if the ISP offers it. otherwise, you send to the standard
smtp port.


if you have a problem sending to some place and that place isn't your
ISP, then that place probably blocks you for some reason. if you tell us
your IP (the IP that gets blocked), we may see if there are problems
with your IP and/or reverse dns. otherwise, we can't help much.



Greg

James D. Parra wrote:

Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2:
to=<[EMAIL PROTECTED]>, relay=none, delay=283474,
delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)


Here's some additional facts:
   1) I have SPF records set up in DNS.
   2) I'm using DomainKeys to verify outgoing messages.

Does anyone know anything about getting email through the
sbcglobal.net servers?  Barring that, does anyone know of a way to
contact someone at sbcglobal for help?  (Email to
[EMAIL PROTECTED] gets no response.)
~~~

Hello Greg,

SBC blocks port 25. You'll need to call their tech support to open the
port
for you.

Best,

~James

Re: SBC Global

[N. Yaakov Ziskind]

James D. Parra wrote (on Wed, Dec 03, 2008 at 03:00:51PM -0800):
> Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to 
> sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
> Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2: 
> to=<[EMAIL PROTECTED]>, relay=none, delay=283474, 
> delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to 
> sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)
> 
> 
> Here's some additional facts:
>1) I have SPF records set up in DNS.
>2) I'm using DomainKeys to verify outgoing messages.
> 
> Does anyone know anything about getting email through the sbcglobal.net 
> servers?  Barring that, does anyone know of a way to contact someone at 
> sbcglobal for help?  (Email to [EMAIL PROTECTED] gets no response.)
> ~~~
> 
> Hello Greg,
> 
> SBC blocks port 25. You'll need to call their tech support to open the port
> for you.
> 
> Best,
> 
> ~James

Sorry for jumping in here, but I'm not sure I understand what you send.
Do you mean that, to send mail to an sbcglobal.net mail address, i have
to train my server to act differently than it does to the gazillion
other addys on the net?

Or, is he (somehow) an sbcglobal subscriber, and he's trying to get
outside? That doesn't seem to be his issue.

Sbcglobal certainly isn't blocking me:
# telnet  sbcmx1.prodigy.net 25
Trying 207.115.21.20...
Connected to sbcmx1.prodigy.net.
Escape character is '^]'.
220 flpi099.prodigy.net ESMTP Sendmail 8.13.8 inb regex/8.13.8; Wed, 3
Dec 2008 15:17:07 -0800
quit
221 2.0.0 flpi099.prodigy.net closing connection
Connection closed by foreign host.

-- 
_
Nachman Yaakov Ziskind, FSPA, LLM   [EMAIL PROTECTED]
Attorney and Counselor-at-Law   http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants

Re: SBC Global

[mouss]

Greg Coates a écrit :
> Of course.  I can't believe I didn't think of that.
> 
> Is there any way to get postfix to _send_ using port 587 for certain
> domains?
> 

587 is for submission, not for MX. if you have an account at an ISP, you
can use 587 if the ISP offers it. otherwise, you send to the standard
smtp port.


if you have a problem sending to some place and that place isn't your
ISP, then that place probably blocks you for some reason. if you tell us
your IP (the IP that gets blocked), we may see if there are problems
with your IP and/or reverse dns. otherwise, we can't help much.


> Greg
> 
> James D. Parra wrote:
>> Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to
>> sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
>> Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2:
>> to=<[EMAIL PROTECTED]>, relay=none, delay=283474,
>> delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to
>> sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)
>>
>>
>> Here's some additional facts:
>>1) I have SPF records set up in DNS.
>>2) I'm using DomainKeys to verify outgoing messages.
>>
>> Does anyone know anything about getting email through the
>> sbcglobal.net servers?  Barring that, does anyone know of a way to
>> contact someone at sbcglobal for help?  (Email to
>> [EMAIL PROTECTED] gets no response.)
>> ~~~
>>
>> Hello Greg,
>>
>> SBC blocks port 25. You'll need to call their tech support to open the
>> port
>> for you.
>>
>> Best,
>>
>> ~James

Re: SBC Global

[Bryan Allen]

+--
| On 2008-12-03 15:14:28, Greg Coates wrote:
| 
| Date: Wed, 03 Dec 2008 15:14:28 -0800
| From: Greg Coates <[EMAIL PROTECTED]>
| To: postfix-users@postfix.org
| Subject: Re: SBC Global
| 
| Of course.  I can't believe I didn't think of that.
| 
| Is there any way to get postfix to _send_ using port 587 for certain 
| domains?
| 
| Greg
| 
| James D. Parra wrote:
| >Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to 
| >sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
| >Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2: 
| >to=<[EMAIL PROTECTED]>, relay=none, delay=283474, 
| >delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to 
| >sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)
| >
| >
| >Here's some additional facts:
| >   1) I have SPF records set up in DNS.
| >   2) I'm using DomainKeys to verify outgoing messages.
| >
| >Does anyone know anything about getting email through the sbcglobal.net 
| >servers?  Barring that, does anyone know of a way to contact someone at 
| >sbcglobal for help?  (Email to [EMAIL PROTECTED] gets no response.)
| >~~~
| >
| >Hello Greg,
| >
| >SBC blocks port 25. You'll need to call their tech support to open the port
| >for you.

I'm pretty sure James misunderstood what you were saying.

SBCGlobal does not block ingress port 25 to their mailservers.

They block egress 25 from their residential networks.

[20081203-18:12:43]:[EMAIL PROTECTED]:[~]$ telnet sbcmx5.prodigy.net 25
Trying 207.115.21.24...
Connected to sbcmx5.prodigy.net.
Escape character is '^]'.
220 flpi129.prodigy.net ESMTP Sendmail 8.13.8 inb regex/8.13.8; Wed, 3 Dec 2008 
15:12:56 -0800
^]

You should contact their mail services people, though, and ask them whiskey
tango. Maybe they are blocking your network for some reason.

Barring that, you might want to see if maybe your routing is hosed to their
systems somehow.

Cheers.
-- 
bda
Cyberpunk is dead.  Long live cyberpunk.
http://mirrorshades.org

Re: SBC Global

[Greg Coates]

Of course.  I can't believe I didn't think of that.

Is there any way to get postfix to _send_ using port 587 for certain 
domains?


Greg

James D. Parra wrote:
Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2: 
to=<[EMAIL PROTECTED]>, relay=none, delay=283474, 
delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)



Here's some additional facts:
   1) I have SPF records set up in DNS.
   2) I'm using DomainKeys to verify outgoing messages.

Does anyone know anything about getting email through the sbcglobal.net 
servers?  Barring that, does anyone know of a way to contact someone at 
sbcglobal for help?  (Email to [EMAIL PROTECTED] gets no response.)

~~~

Hello Greg,

SBC blocks port 25. You'll need to call their tech support to open the port
for you.

Best,

~James

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

[mouss]

Roderick A. Anderson a écrit :
> Magnus Bäck wrote:
>> [snip]
>> Why do you insist on testing this with telnet? You will introduce
>> another possible error source (incorrect encoding of the credentials)
>> and it's a use case that you're supposedly not really interested in.
> 
> Because I can do it one step at a time and see the results that Postfix
> sends back.  I hadn't thought of telnet possibly munging base64 encoded
> values.  They looked like ASCII-only to me.
> 

well, you said you tried google and possibly other things. but did you try
http://www.postfix.org/SASL_README.html#server_test

but it's easier to write a perl/whatever script to do your tests instead
of a "plain" telnet.


>>
>> [...]
>>
>>> alias_database = hash:/etc/postfix/aliases
>>> alias_maps = hash:/etc/postfix/aliases
>>
>> Useless since local_transport != local.
> 
> Thanks.  This was built by looking at _many_ HOWTOs and documentation
> pages and based on a working non-virtual main.cf file.
> 


unfortunately, very few howtos are worth reading...

>>
>> [...]
>>
>>> local_recipient_maps = local_transport = virtual
>>
>> Why fight the system? If a domain is a virtual mailbox domain, list the
>> domain in virtual_mailbox_domains and leave local_transport alone.
> 
> Again thanks.  I'll study up on this but, as above, it came from far too
> many sources of information.  I got it working, for the most part, and
> then let it ride.  I think it might have been done this way because I'm
> using Dovecot's deliver and dovecot-sieve.  Could have been because I'm
> putting mail in /var/mail/vhosts/%d/%u/ and have per-domain password
> files.  Who knows; someday I too might learn think and speak SMTP like a
> native and get it all correct.
> 

As Magnus said, don't fight against the system. if you want virtual
domains, and only virtual domains, configure your domains to be virtual
and if needed, disable local delivery.

RE: SBC Global

[James D. Parra]

Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2: 
to=<[EMAIL PROTECTED]>, relay=none, delay=283474, 
delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)


Here's some additional facts:
   1) I have SPF records set up in DNS.
   2) I'm using DomainKeys to verify outgoing messages.

Does anyone know anything about getting email through the sbcglobal.net 
servers?  Barring that, does anyone know of a way to contact someone at 
sbcglobal for help?  (Email to [EMAIL PROTECTED] gets no response.)
~~~

Hello Greg,

SBC blocks port 25. You'll need to call their tech support to open the port
for you.

Best,

~James

SBC Global

[Greg Coates]

I'm running a relatively new mail server.  I've managed to get my server 
to send to pretty much all email addresses except for one server: 
sbcglobal.net.  When I try to send emails to sbcglobal.net customers, 
postfix's connection attempts time out.  Every time.  This has been 
happening 100% of the time for at least six months.


Here's a sample from my mail logs:

Nov 30 05:52:58 mydomain postfix/smtp[28398]: connect to 
sbcmx3.prodigy.net[207.115.21.22]: Connection timed out (port 25)
Nov 30 05:53:28 mydomain postfix/smtp[28398]: connect to 
sbcmx9.prodigy.net[207.115.37.23]: Connection timed out (port 25)
Nov 30 05:53:58 mydomain postfix/smtp[28398]: connect to 
sbcmx7.prodigy.net[207.115.37.21]: Connection timed out (port 25)
Nov 30 05:54:28 mydomain postfix/smtp[28398]: connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out (port 25)
Nov 30 05:54:28 mydomain postfix/smtp[28398]: 3980347D80A2: 
to=<[EMAIL PROTECTED]>, relay=none, delay=283474, 
delays=283324/0.04/150/0, dsn=4.4.1, status=deferred (connect to 
sbcmx5.prodigy.net[207.115.21.24]: Connection timed out)



Here's some additional facts:
  1) I have SPF records set up in DNS.
  2) I'm using DomainKeys to verify outgoing messages.

Does anyone know anything about getting email through the sbcglobal.net 
servers?  Barring that, does anyone know of a way to contact someone at 
sbcglobal for help?  (Email to [EMAIL PROTECTED] gets no response.)


Thanks,
Greg Coates

Re: Avoiding (trivial) spoofed "mail from"

[DJ Lucas]

LuKreme wrote:
> On 2-Dec-2008, at 20:21, DJ Lucas wrote:
>> I can find absolutely no reason to inadvertently mislead, or worse,
>> intentionally deceive the recipient by forging the envelope sender's
>> address.  In fact, the only reason I can see, is
>> to intentionally deceive the recipient.  Is there any other reason?
>
> Sure there is.  

No there isn't.  AFAIK, unless I'm misunderstanding something, the rest
of your message simply puts what I said above in different terms and
agrees entirely.  **my mom** was in the From header...nowhere else.  
The From header can be changed up to say that it came from somebody
else.  I don't care about that.  The check in question is in the smtp
transaction, not the data.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Roderick A. Anderson]

Magnus Bäck wrote:

On Wednesday, December 03, 2008 at 19:52 CET,
 "Roderick A. Anderson" <[EMAIL PROTECTED]> wrote:


I'm trying to test my Postfix/Dovecot set up to determine why (what
I'm doing wrong) a Perl script using Mail::Sender is failing.  Errors
say connection failed -- rather ambiguous I'd say!  :-)


Please post full logs instead of anecdotes. Right now it's not even
obvious that it's Postfix that's complaining. For SASL debugging help
output from saslfinger is often useful (or perhaps not that useful with
Dovecot).


Sorry.




This is for a system with multiple (virtual?) domains.

I'm using telnet to test but am having a problem figuring out what I 
should use for the actual username before it is base64 encoded.


You can choose any username you like as long as it matches whatever is
in your credential database. So far we don't know anything about that.
MySQL, sasldb, LDAP, what?


smtpd_sasl_type = dovecot


I'm having no problems using the system and Thunderbird seems to have
done the right thing when I created the SMTP server settings for each
of the domains.

I did not find any examples via Google and both the Postfix and
Dovecot sites using telnet to test with virtual domains.


Why do you insist on testing this with telnet? You will introduce
another possible error source (incorrect encoding of the credentials)
and it's a use case that you're supposedly not really interested in.


Because I can do it one step at a time and see the results that Postfix 
sends back.  I hadn't thought of telnet possibly munging base64 encoded 
values.  They looked like ASCII-only to me.




[...]


alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases


Useless since local_transport != local.


Thanks.  This was built by looking at _many_ HOWTOs and documentation 
pages and based on a working non-virtual main.cf file.




[...]

local_recipient_maps = 
local_transport = virtual


Why fight the system? If a domain is a virtual mailbox domain, list the
domain in virtual_mailbox_domains and leave local_transport alone.


Again thanks.  I'll study up on this but, as above, it came from far too 
many sources of information.  I got it working, for the most part, and 
then let it ride.  I think it might have been done this way because I'm 
using Dovecot's deliver and dovecot-sieve.  Could have been because I'm 
putting mail in /var/mail/vhosts/%d/%u/ and have per-domain password 
files.  Who knows; someday I too might learn think and speak SMTP like a 
native and get it all correct.



Rod
--

Re: DKIM message forwarding, body altered

[David Jonas]

Victor Duchovni wrote:
> On Tue, Dec 02, 2008 at 10:02:37AM -0800, David Jonas wrote:
>
>   
>>> What version of Postfix are you using?
>>>   
>> 2.3.8 and 2.4.6-- yea, we're a little behind. Perhaps I'll bring us up
>> to 2.5 today.
>> 
>
> I am not aware of any "transparency" issues in either of those releases.
> You don't need to upgrade. There was once an undesirable interaction
> between "transparency" and 8-bit to 7-bit conversion, but that was
> in Postfix 2.0 snapshot (at the time called 1.1.N-MMDD) releases.
> This was fixed before 2.0.0.
>   
Updated to 2.5.5

 @@ -92,6 +83,7 @@
 -=20
 +.=20
 
>>> Most likely Ebay sending software fails to implement RFC 821/2821/5281
>>> correctly:
>>>
>>> http://tools.ietf.org/html/rfc5321#section-4.5.2
>>>
>>> not much you can do about that. Postfix can't possibly know all
>>> the places in which the Ebay software screwed up.
>>>
>>> The RFC is quite clear, leading "." characters in SMTP are stripped
>>> regardless of the following character. Some MTAs only trim "." when
>>> the next character is also a ".", but this violates the RFC.
>>>   
>> I will attempt to file a bug with eBay/PayPal. Thanks. I'm going to try
>> to set up a clean environment (no processing at all) to make sure this
>> is definitely real and not just a side effect.  Nothing touches the body
>> right now, but the message does get juggled a bit before being sent out
>> again.
>> 
>
> A tcpdump capturing the SMTP traffic from EBAY should show the lack
> of propper "dot-stuffing" in their sending engine.
>
> If they do it correctly, perhaps you have content filters or down-stream
> SMTP senders that are broken. What software other than Postfix do
> the messages traverse before forwarding?
>
>   
I found the culprit.

To get an X-Original-To header on the forwarded emails they get run
through pipe and back to postfix with smtpclient
(http://www.freebsdsoftware.org/mail/smtpclient.html):

xorig unix  -   n   n   -   -  pipe
  flags=Ohuq user=smtpclient argv=/usr/bin/smtpclient
  -w -S 127.0.0.1 -P 4525 -f ${sender} -- ${recipient}

We also use smtpclient to pass the messages back from spamc to a special
port.

A quick test showed that smtpclient was stripping that dot. I sincerely
apologize for the noise, but I did learn a lot here. Thanks for the help.

Any other options besides smtpclient to pass the message back to a
different port? This is already a multi-instance setup, one for regular
incoming mail/backup mx'ing and another for filtering the local and
forwarding mail.

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

[Magnus Bäck]

On Wednesday, December 03, 2008 at 19:52 CET,
 "Roderick A. Anderson" <[EMAIL PROTECTED]> wrote:

> I'm trying to test my Postfix/Dovecot set up to determine why (what
> I'm doing wrong) a Perl script using Mail::Sender is failing.  Errors
> say connection failed -- rather ambiguous I'd say!  :-)

Please post full logs instead of anecdotes. Right now it's not even
obvious that it's Postfix that's complaining. For SASL debugging help
output from saslfinger is often useful (or perhaps not that useful with
Dovecot).

> This is for a system with multiple (virtual?) domains.
>
> I'm using telnet to test but am having a problem figuring out what I 
> should use for the actual username before it is base64 encoded.

You can choose any username you like as long as it matches whatever is
in your credential database. So far we don't know anything about that.
MySQL, sasldb, LDAP, what?

> I'm having no problems using the system and Thunderbird seems to have
> done the right thing when I created the SMTP server settings for each
> of the domains.
>
> I did not find any examples via Google and both the Postfix and
> Dovecot sites using telnet to test with virtual domains.

Why do you insist on testing this with telnet? You will introduce
another possible error source (incorrect encoding of the credentials)
and it's a use case that you're supposedly not really interested in.

[...]

> alias_database = hash:/etc/postfix/aliases
> alias_maps = hash:/etc/postfix/aliases

Useless since local_transport != local.

[...]

> local_recipient_maps = 
> local_transport = virtual

Why fight the system? If a domain is a virtual mailbox domain, list the
domain in virtual_mailbox_domains and leave local_transport alone.

[...]

-- 
Magnus Bäck
[EMAIL PROTECTED]

Testing SASL HOWTO using telnet/Postfix/dovecot?

[Roderick A. Anderson]

I'm trying to test my Postfix/Dovecot set up to determine why (what I'm 
doing wrong) a Perl script using Mail::Sender is failing.  Errors say 
connection failed -- rather ambiguous I'd say!  :-)


This is for a system with multiple (virtual?) domains.

I'm using telnet to test but am having a problem figuring out what I 
should use for the actual username before it is base64 encoded.


I'm having no problems using the system and Thunderbird seems to have 
done the right thing when I created the SMTP server settings for each of 
the domains.


I did not find any examples via Google and both the Postfix and Dovecot 
sites using telnet to test with virtual domains.


This is on a CentOS 5 guest (Linux-Vserver).

postfix-2.3.3-2.1.el5_2
postgrey-1.31-1.el5.rf
dovecot-1.1.3-0_80.el5
dovecot-sieve-1.1.5-8.el5

The output of postconf -n is attached.

Pointers/suggestions?


TIA
Rod
--
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
default_destination_concurrency_limit = 10
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
inet_interfaces = nnn.nn.nnn.nnn, 127.0.0.1
local_recipient_maps = 
local_transport = virtual
message_size_limit = 20971520
mydestination = localhost
mydomain = domain.tld
myhostname = mx0.domain2.tld
mynetworks = 127.0.0.0/8
recipient_delimiter = +
smtp_bind_address = nnn.nn.nnn.nnn
smtpd_data_restrictions = reject_unauth_pipelining, 
reject_multi_recipient_bounce smtpd_discard_ehlo_keywords = silent-discard, dsn
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_invalid_hostname reject_non_fqdn_hostname
smtpd_recipient_restrictions = reject_non_fqdn_sender, 
reject_non_fqdn_recipient, permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination, reject_unlisted_recipient, 
reject_invalid_helo_hostname, reject_unknown_sender_domain, 
reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, 
check_policy_service unix:postgrey/socket, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.pem
smtpd_tls_key_file = /etc/pki/tls/private/mail.pem
smtpd_tls_security_level = may
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_domains = $mydomain, domain1.tld, domain2.tld
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 500
virtual_transport = dovecot
virtual_uid_maps = static:5000

Re: Unknow user for existing local users

[Sebastien Marion]

Nice one, you actually have it spot on :-)
Thanks a lot, I guess I wasn't looking where I should have been...

Regards,

Sebastien Marion




On 3 Dec 2008, at 18:21, Victor Duchovni wrote:


On Wed, Dec 03, 2008 at 06:06:18PM +, Sebastien Marion wrote:


Thank you Wietse.

Sorry, I meant Maildir of course.
I'm looking into ~/Maildir/cur/ and nothing new pops in.



Look in ~/Maildir/new, mail is moved to "cur" by MUAs, MTAs deliver
to "new". This assumes that you are in fact using "home_maildir" to
put mail into ~/Mail/... You still have not posted "postconf -n",
and if your problem is not solved yet, you'll probably not get further
help without doing so.

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Unknow user for existing local users

[Victor Duchovni]

On Wed, Dec 03, 2008 at 06:06:18PM +, Sebastien Marion wrote:

> Thank you Wietse.
> 
> Sorry, I meant Maildir of course.
> I'm looking into ~/Maildir/cur/ and nothing new pops in.
> 

Look in ~/Maildir/new, mail is moved to "cur" by MUAs, MTAs deliver
to "new". This assumes that you are in fact using "home_maildir" to
put mail into ~/Mail/... You still have not posted "postconf -n",
and if your problem is not solved yet, you'll probably not get further
help without doing so.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Unknow user for existing local users

[Sebastien Marion]

Thank you Wietse.

Sorry, I meant Maildir of course.
I'm looking into ~/Maildir/cur/ and nothing new pops in.

Regards,

Sebastien Marion




On 3 Dec 2008, at 17:27, Wietse Venema wrote:


Sebastien Marion:

Thank you Terry,

Logs say:

Dec  3 17:06:09 stock postfix/local[9123]: 1B5CA10369:
to=<[EMAIL PROTECTED]>, relay=local, delay=0.04, delays=0.02/0.02/0/0,
dsn=2.0.0, status=sent (delivered to maildir)

But nothing actually appeared in that very Mailbox...


This delivers to mailDIR, not mailBOX file.

Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Re: limits

[polloxx]

On Wed, Dec 3, 2008 at 11:25 AM, Leonardo Rodrigues Magalhães
<[EMAIL PROTECTED]> wrote:
>
>
> polloxx escreveu:
>>
>> Dear group,
>>
>> We want to limit the number of mails a given IP address can send per
>> time unit (outbound).
>> What do you use to resolve this with a postfix server?
>> We want a flexible method were we can set the number of allowed mails
>> per time unit per IP address (in a SQL datbase).
>>
>
>   postfix cant do that alone. you'll need some policy server for that task.
> I would suggest policyd. It allows you to define throttling based on IP
> address and even on SASL-authenticated username. Data is stored in a MySQL
> database who can be managed with the web interface that comes with it or you
> can develop your own interface, even using the standard one as a template.
>
> http://www.policyd.org/
>

Thanks,
P.

Re: sender restrictions

[Victor Duchovni]

On Wed, Dec 03, 2008 at 09:25:04AM -0600, Cengiz Vural wrote:

> > smtpd_sender_restrictions =
> > check_sender_access regexp:/etc/postfix/tables/access
> >
> > and
> >
> > created /etc/postfix/tables/access
> >
> > [EMAIL PROTECTED]REDIRECT [EMAIL PROTECTED]
> >
> > Ran postmap /etc/postfix/tables/access ...

Don't "postmap" regexp tables. If you leave off the "regexp:" prefix,
it builds a database of the default type, usually "hash" or "dbm",
which will not be used. If you don't leave the prefix off, postmap(1)
will rightly complain that "regexp" tables can't be indexed.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Unknow user for existing local users

[Wietse Venema]

Sebastien Marion:
> Thank you Terry,
> 
> Logs say:
> 
> Dec  3 17:06:09 stock postfix/local[9123]: 1B5CA10369:  
> to=<[EMAIL PROTECTED]>, relay=local, delay=0.04, delays=0.02/0.02/0/0,  
> dsn=2.0.0, status=sent (delivered to maildir)
> 
> But nothing actually appeared in that very Mailbox...

This delivers to mailDIR, not mailBOX file.

Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Re: Unknow user for existing local users

[Victor Duchovni]

On Wed, Dec 03, 2008 at 04:46:09PM +, Sebastien Marion wrote:

> Thank you Terry,
> 
> Logs say:
> 
> Dec  3 17:06:09 stock postfix/local[9123]: 1B5CA10369:  
> to=<[EMAIL PROTECTED]>, relay=local, delay=0.04, delays=0.02/0.02/0/0,  
> dsn=2.0.0, status=sent (delivered to maildir)
> 
> But nothing actually appeared in that very Mailbox...

When you say "that" you know what it means, but nobody here does,
please don't assume we are psychic and post the relevant details:

- "postconf -n" details
- The meaning of "that'. Where are you expecting the mail
  to be delivered?

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Unknow user for existing local users

[Sebastien Marion]

Thank you Terry,

Logs say:

Dec  3 17:06:09 stock postfix/local[9123]: 1B5CA10369:  
to=<[EMAIL PROTECTED]>, relay=local, delay=0.04, delays=0.02/0.02/0/0,  
dsn=2.0.0, status=sent (delivered to maildir)


But nothing actually appeared in that very Mailbox...

I've looked at the chmod, but it seems OK to me.

Regards,


Sebastien Marion





On 3 Dec 2008, at 16:36, Terry Carmen wrote:


Sebastien Marion wrote:

Hi again,

I've gone forward, there was apparently some old exim4 .forward  
files hanging about... as somebody else found out.

So I've removed them, and emails do not bounce anymore.

What happens now is that postfix is all happy but the emails do  
not seem to arrive in the relevant Maildir.


Any idea where they go and how to put them back where they  
*should* go?



The log file knows all.

Take a look at /var/log/maillog (or your mail log location, if  
different) and see what happens to mail when it comes in.


It will show where each message enters your system and how it exits:

Dec  3 11:29:07 wormhole postfix/local[20323]: 5143430415:  
to=<[EMAIL PROTECTED]>, relay=local, delay=0.42,  
delays=0.31/0/0/0.12, dsn=2.0.0, status=sent (delivered to maildir)


Terry

Re: Unknow user for existing local users

[Terry Carmen]

Sebastien Marion wrote:

Hi again,

I've gone forward, there was apparently some old exim4 .forward files 
hanging about... as somebody else found out.

So I've removed them, and emails do not bounce anymore.

What happens now is that postfix is all happy but the emails do not 
seem to arrive in the relevant Maildir.


Any idea where they go and how to put them back where they *should* go?


The log file knows all.

Take a look at /var/log/maillog (or your mail log location, if 
different) and see what happens to mail when it comes in.


It will show where each message enters your system and how it exits:

Dec  3 11:29:07 wormhole postfix/local[20323]: 5143430415: 
to=<[EMAIL PROTECTED]>, relay=local, delay=0.42, 
delays=0.31/0/0/0.12, dsn=2.0.0, status=sent (delivered to maildir)


Terry

Re: Unknow user for existing local users

[Sebastien Marion]

Hi again,

I've gone forward, there was apparently some old exim4 .forward files  
hanging about... as somebody else found out.

So I've removed them, and emails do not bounce anymore.

What happens now is that postfix is all happy but the emails do not  
seem to arrive in the relevant Maildir.


Any idea where they go and how to put them back where they *should* go?

Many thanks,

Sebastien Marion





On 3 Dec 2008, at 16:18, Wietse Venema wrote:


Sebastien Marion:

Hi all,

I've been bashing my head at this for 2 days now.

I can send and receive emails nicely from my address.
My colleagues however cannot receive emails as postfix bounces them
back. They are part of the system (debian users).



mydestination = whizlogic.co.uk, ks300575.kimsufi.com,  ...


You have configured Postfix to deliver all mail for whizlogic.co.uk
on your local machine. Is this really what you want?

If not, have a look at http://www.postfix.org/SOHO_README.html

Wietse

Re: Unknow user for existing local users

[Wietse Venema]

Sebastien Marion:
> >> I've been bashing my head at this for 2 days now.
> >>
> >> I can send and receive emails nicely from my address.
> >> My colleagues however cannot receive emails as postfix bounces them
> >> back. They are part of the system (debian users).
> >
> >> mydestination = whizlogic.co.uk, ks300575.kimsufi.com,  ...
> >
> > You have configured Postfix to deliver all mail for whizlogic.co.uk
> > on your local machine. Is this really what you want?
> 
> Sure, this the company server.

Then follow instrucions in the mailing list welcome message.

Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Re: Unknow user for existing local users

[Sebastien Marion]

On 3 Dec 2008, at 16:18, Wietse Venema wrote:


Sebastien Marion:

Hi all,

I've been bashing my head at this for 2 days now.

I can send and receive emails nicely from my address.
My colleagues however cannot receive emails as postfix bounces them
back. They are part of the system (debian users).



mydestination = whizlogic.co.uk, ks300575.kimsufi.com,  ...


You have configured Postfix to deliver all mail for whizlogic.co.uk
on your local machine. Is this really what you want?


Sure, this the company server.



If not, have a look at http://www.postfix.org/SOHO_README.html

Wietse



Regards,

Sebastien Marion

Re: Unknow user for existing local users

[Wietse Venema]

Sebastien Marion:
> Hi all,
> 
> I've been bashing my head at this for 2 days now.
> 
> I can send and receive emails nicely from my address.
> My colleagues however cannot receive emails as postfix bounces them  
> back. They are part of the system (debian users).

> mydestination = whizlogic.co.uk, ks300575.kimsufi.com,  ...

You have configured Postfix to deliver all mail for whizlogic.co.uk
on your local machine. Is this really what you want?

If not, have a look at http://www.postfix.org/SOHO_README.html

Wietse

Re: Avoiding (trivial) spoofed "mail from"

[J.P. Trosclair]

LuKreme wrote:

On 2-Dec-2008, at 20:21, DJ Lucas wrote:
I can find absolutely no reason to inadvertently mislead, or worse,  
intentionally deceive the recipient by forging the envelope sender's  
address.  In fact, the only reason I can see, is to intentionally  
deceive the recipient.  Is there any other reason?


Sure there is.  First off, the envelope from is not FOR the user, it's  
for the mailserver.  This address should always be where the  
'physical' delivery of the message is originating.  The From header is  
the PERSON that initiated the message.  These are often the same, but  
not always.


A perfect example is my mom sends out electronic  cards from Jacquie  
Lawson<1> which arrive with headers like this:


Return-Path: <[EMAIL PROTECTED]>
Received: from iport3.jacquielawson.com (iport3.jacquielawson.com  
[64.14.122.52])

by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F
for <[EMAIL PROTECTED]>; Thu, 27 Nov 2008 02:27:05 -0700 (MST)
Date: Thu, 27 Nov 2008 04:27:02 -0500
X-AG-MIPS: ag867
Sender: <[EMAIL PROTECTED]>
From: **my mom**



I don't see how this particular case would be affected. The only 
"forged" part was in the header that I can see from your example, not 
the actual MAIL FROM during the initial part of the SMTP conversation.


Currently I have our configuration set to reject mail claiming a MAIL 
FROM that originates in our domain if the session has not been 
authenticated or coming from the local network.


Example where MAIL FROM is not forged, but From part of header is:
$ telnet mail1.omitted_for_privacy.com 25
Trying x.x.x.x...
Connected to mail1.omitted_for_privacy.com.
Escape character is '^]'.
220 mail1.omitted_for_privacy.com ESMTP
EHLO omitted_for_privacy.com
250-mail1.omitted_for_privacy.com
250-PIPELINING
250-SIZE 2147483647
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:[EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO:[EMAIL PROTECTED]
250 2.1.5 Ok
DATA
354 End data with .
From: [EMAIL PROTECTED]
Subject: proof that only the mail from portion is rejected
This email should be accepted by our mail server
.
250 2.0.0 Ok: queued as 241056A006F
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Example where MAIL FROM is forged:
$ telnet mail1.omitted_for_privacy.com 25
Trying 12.48.244.4...
Connected to mail1.omitted_for_privacy.com.
Escape character is '^]'.
220 mail1.omitted_for_privacy.com ESMTP
EHLO judelawfirm.com
250-mail1.omitted_for_privacy.com
250-PIPELINING
250-SIZE 2147483647
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:[EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO:[EMAIL PROTECTED]
554 5.7.1 <[EMAIL PROTECTED]>: Sender address 
rejected: Not authenticated

QUIT
221 2.0.0 Bye
Connection closed by foreign host.


This is perfectly OK.  In fact, this is exactly how this should be  
handled. 


I agree completely, I do not think it's OK to forge the MAIL FROM 
portion of the SMTP conversation though. I think this is what DJ Lucas 
was getting at.


This method is also used when someone is sending, for  
example, a petition request where they've 'signed' and want to let  
others know to sign also.  Many pages (particularly political ones)  
have these sorts of "tell your friends" links and they to will use the  
person's email/name as the from and their own server info for the  
envelope.  I would be far more likely to take a look at the FROM_ and  
compare it to the Received header than with the From: header, as I  
think that is far more likely to spot spam.


Extending this to a physical letter situation it would be like Barack  
Obama's campaign sending me a letter that was signed by, say, my mom.   
She wrote the letter and signed it, but the campaign office mailed it  
in their own envelope.  Seems fine to me.


If they don't like my policy, they can find another place to put  
their mail.  Others may not be lucky enough to be able to enforce  
such a policy, as the counter argument would be to find a less rigid  
admin. ;-)  What is 'acceptable' has to be determined on a site by  
site basis.  If it works for this site...great!  If it doesn't, then  
get rid of it.


Just so you know that there are common and legitimate uses for this,  
and that you will lose valid emails that, presumably, your users  
actually want.  And if you are rejecting them, do your users know they  
are missing those emails?  I mean, are they informed enough that they  
can make a real choice about getting MOST of their email from you or  
getting ALL of their email from someone else?


<1> I have no connection with Jacquie Lawson.  I'm not even a  
customer, I am merely a recipient.  I do like the cards though.




At this point I think there is some confusion about what is being stated 
is acceptable and what is not.

Unknow user for existing local users

[Sebastien Marion]

Hi all,

I've been bashing my head at this for 2 days now.

I can send and receive emails nicely from my address.
My colleagues however cannot receive emails as postfix bounces them  
back. They are part of the system (debian users).


It's a though /etc/passwd wasn't read by postfix.

Logs tell me "(unknown user)".

My main.cfg is as follows:

 
 
--
# See /usr/share/postfix/main.cf.dist for a commented, more complete  
version



# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
#smtpd_use_tls=yes
#smtpd_tls_session_cache_database = btree:${queue_directory}/ 
smtpd_scache

#smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package  
for

# information on enabling SSL in the smtp client.

#myhostname = ks300575.kimsufi.com
myhostname = whizlogic.co.uk
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
local_recipient_maps = unix:passwd.byname $alias_maps
myorigin = /etc/mailname
mydestination = whizlogic.co.uk, ks300575.kimsufi.com,  
localhost.kimsufi.com, localhost

relayhost =
mynetworks = 127.0.0.0/8
mailbox_command =

mailbox_size_limit = 0

recipient_delimiter = +
inet_interfaces = all

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_sasl_application_name = smtpd
broken_sasl_auth_clients = yes

smtpd_recipient_restrictions =  
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination


smtpd_tls_security_level = may


home_mailbox = Maildir/
smtp_tls_key_file = /etc/postfix/tls/smtpd.key
smtp_tls_cert_file = /etc/postfix/tls/smtpd.crt
smtp_tls_CAfile = /etc/postfix/tls/cacert.pem
smtp_tls_session_cache_database = btree:$data_directory/ 
smtp_tls_session_cache

smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes

smtpd_tls_key_file = /etc/postfix/tls/smtpd.key
smtpd_tls_cert_file = /etc/postfix/tls/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem
smtpd_tls_session_cache_database = btree:$data_directory/ 
smtpd_tls_session_cache

smtpd_use_tls = yes

smtpd_tls_received_header = yes
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 3

tls_random_source = dev:/dev/urandom

# TLS PART END


 
-




Any ideas?

Many thanks,


Sebastien Marion

Re: Avoiding (trivial) spoofed "mail from"

[LuKreme]

On 2-Dec-2008, at 20:21, DJ Lucas wrote:
I can find absolutely no reason to inadvertently mislead, or worse,  
intentionally deceive the recipient by forging the envelope sender's  
address.  In fact, the only reason I can see, is to intentionally  
deceive the recipient.  Is there any other reason?


Sure there is.  First off, the envelope from is not FOR the user, it's  
for the mailserver.  This address should always be where the  
'physical' delivery of the message is originating.  The From header is  
the PERSON that initiated the message.  These are often the same, but  
not always.


A perfect example is my mom sends out electronic  cards from Jacquie  
Lawson<1> which arrive with headers like this:


Return-Path: <[EMAIL PROTECTED]>
Received: from iport3.jacquielawson.com (iport3.jacquielawson.com  
[64.14.122.52])

by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F
for <[EMAIL PROTECTED]>; Thu, 27 Nov 2008 02:27:05 -0700 (MST)
Date: Thu, 27 Nov 2008 04:27:02 -0500
X-AG-MIPS: ag867
Sender: <[EMAIL PROTECTED]>
From: **my mom**

This is perfectly OK.  In fact, this is exactly how this should be  
handled. This method is also used when someone is sending, for  
example, a petition request where they've 'signed' and want to let  
others know to sign also.  Many pages (particularly political ones)  
have these sorts of "tell your friends" links and they to will use the  
person's email/name as the from and their own server info for the  
envelope.  I would be far more likely to take a look at the FROM_ and  
compare it to the Received header than with the From: header, as I  
think that is far more likely to spot spam.


Extending this to a physical letter situation it would be like Barack  
Obama's campaign sending me a letter that was signed by, say, my mom.   
She wrote the letter and signed it, but the campaign office mailed it  
in their own envelope.  Seems fine to me.


If they don't like my policy, they can find another place to put  
their mail.  Others may not be lucky enough to be able to enforce  
such a policy, as the counter argument would be to find a less rigid  
admin. ;-)  What is 'acceptable' has to be determined on a site by  
site basis.  If it works for this site...great!  If it doesn't, then  
get rid of it.


Just so you know that there are common and legitimate uses for this,  
and that you will lose valid emails that, presumably, your users  
actually want.  And if you are rejecting them, do your users know they  
are missing those emails?  I mean, are they informed enough that they  
can make a real choice about getting MOST of their email from you or  
getting ALL of their email from someone else?


<1> I have no connection with Jacquie Lawson.  I'm not even a  
customer, I am merely a recipient.  I do like the cards though.


--
<[TN]FBMachine> i got kicked out of Barnes and Noble once for
moving all the bibles into the fiction section

Re: sender restrictions

[Cengiz Vural]

On Wed, Dec 3, 2008 at 9:22 AM, Cengiz Vural <[EMAIL PROTECTED]> wrote:

>
>
> On Tue, Dec 2, 2008 at 2:18 PM, Victor Duchovni <
> [EMAIL PROTECTED]> wrote:
>
>> On Tue, Dec 02, 2008 at 02:05:20PM -0600, Cengiz Vural wrote:
>>
>> > hello all,
>> >
>> > I am trying to place some restrictions on a local user account. I would
>> like
>> > to redirect any emails sent from a specific user to another local user
>> > regardless of what email address the user enters in the recipient
>> list.Is it
>> > possible to do this with postfix?
>> >
>> > In summary, whenever [EMAIL PROTECTED] sends an email, I want that email
>> to be
>> > delivered to [EMAIL PROTECTED] only.
>>
>> Is the mail submitted via SMTP or via sendmail(1)? If the former, you
>> can use "REDIRECT" (see access(5)) via "check_sender_access type:table"
>> in smtpd_sender_restrictions. If the latter, your best bet is to
>> content_filter local mail to a local SMTP re-injection port, but this
>> significantly raises the disk I/O cost of local mail submission.
>>
>> --
>>Viktor.
>>
>> Disclaimer: off-list followups get on-list replies or get ignored.
>> Please do not ignore the "Reply-To" header.
>>
>> To unsubscribe from the postfix-users list, visit
>> http://www.postfix.org/lists.html or click the link below:
>> 
>>
>> If my response solves your problem, the best way to thank me is to not
>> send an "it worked, thanks" follow-up. If you must respond, please put
>> "It worked, thanks" in the "Subject" so I can delete these quickly.
>>
>
> Thanks for the quick answer, Viktor. I added the lines below to my 
> main.cffile.
>
> smtpd_sender_restrictions =
> check_sender_access regexp:/etc/postfix/tables/access
>
> and
>
> created /etc/postfix/tables/access
>
> [EMAIL PROTECTED]REDIRECT [EMAIL PROTECTED]
>
> Ran postmap /etc/postfix/tables/access and reloaded postfix but it ignores
> all these. What am I doing wrong?
>
> -Cengiz
>
>
I am sorry. Please disregard this message. It is working.

-Cengiz

Re: sender restrictions

[Cengiz Vural]

On Tue, Dec 2, 2008 at 2:18 PM, Victor Duchovni <
[EMAIL PROTECTED]> wrote:

> On Tue, Dec 02, 2008 at 02:05:20PM -0600, Cengiz Vural wrote:
>
> > hello all,
> >
> > I am trying to place some restrictions on a local user account. I would
> like
> > to redirect any emails sent from a specific user to another local user
> > regardless of what email address the user enters in the recipient list.Is
> it
> > possible to do this with postfix?
> >
> > In summary, whenever [EMAIL PROTECTED] sends an email, I want that email to
> be
> > delivered to [EMAIL PROTECTED] only.
>
> Is the mail submitted via SMTP or via sendmail(1)? If the former, you
> can use "REDIRECT" (see access(5)) via "check_sender_access type:table"
> in smtpd_sender_restrictions. If the latter, your best bet is to
> content_filter local mail to a local SMTP re-injection port, but this
> significantly raises the disk I/O cost of local mail submission.
>
> --
>Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> 
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>

Thanks for the quick answer, Viktor. I added the lines below to my main.cffile.

smtpd_sender_restrictions =
check_sender_access regexp:/etc/postfix/tables/access

and

created /etc/postfix/tables/access

[EMAIL PROTECTED]REDIRECT [EMAIL PROTECTED]

Ran postmap /etc/postfix/tables/access and reloaded postfix but it ignores
all these. What am I doing wrong?

-Cengiz


-- 
Cengiz Vural <[EMAIL PROTECTED]>
Fax. (641) 795-4388
Phone. (512) 524-7215

Re: FW: Help Needed with odd configuration...

[Wietse Venema]

Spahn, Daniel:
Spahn, Daniel wrote:
> I am running A recent build of Postfix on a Gentoo server- I am pretty 
> sure it is about 3-4 months old. The problem I have is that the line the 
> mail is sent out on is buggy- I get lots of packet sequence errors, slow 
> speeds, etc. I need any advice I can get on configuring fault 

If the network suffers from congestion, increase timeouts.

If the network suffers from harware-level errors (checksum errors),
replace/reset/reboot defective hardware.

If the network suffers from protocol-level errors, kill off selective
acks, window scaling, IP path MTU discovery, shrink the TCP maximal
segment size, and so on.

Wietse

Re: Avoiding (trivial) spoofed "mail from"

[Noel Jones]

DJ Lucas wrote:

Noel Jones wrote:


Very likely there are other, better ways to combat this spam.  Look 
for other traits you can use to reject it.


I am, by no means, anything even close to expert WRT the whole SMTP 
process, but, I do think that I can provide (or at least what I believe 
to be) a valid, albeit opinionated, counter argument.  See below.

some things to look for:
- client listed on some RBL
- client name that looks dynamic
- using your domain or IP as HELO
- unusual headers
- body text unlikely to be found in legit mail

If that doesn't help, consider adding SpamAssassin and/or ClamAV.
 From my POV, this one check saves me a small few (100, 200?) DNS/RBL 
lookups per month and a few CPU cycles by not getting to header checks, 
body checks, and finally SA (which is probably the most expensive check 
in the stack, followed immediately by virus scanning).  I can probably 
parse my logs and give a real number, but it would seem insignificant to 
those running large servers.  It is my _choice_ to be as efficient as 
possible.



Please correct me if I've made an invalid assumption (but do take notice 
of the "IMO" qualifier!)


I can find absolutely no reason to inadvertently mislead, or worse, 
intentionally deceive the recipient by forging the envelope sender's 
address.  In fact, the only reason I can see, is to intentionally 
deceive the recipient.  Is there any other reason?
It is plain irresponsible, even if allowed by RFC.  Even more so given 
that most (all?) mail clients will honor the from header and display it, 
in big, bright, flashy, bold text, in a prominent location for the end 
user to see (and reply to).  Maybe I've missed something, but I really 
cannot find a good reason to allow it.  Even the BlackBerry example 
given above is an example of poor practice in my opinion, but it can be 
an ALLOWed exception if it is out of your control.


But that is all a matter of principal, not a technical reason.   The 
technical reason (minor increase in efficiency) was above, but I also 
provide one more weak technical argument.  Another possible (but pretty 
unlikely now days) side effect of allowing such message mangling to 
occur is that it could lead to backscatter if an intermediate server is 
mis-configured.  That is not my problem if it is 'properly' denied at 
the door and not allowed (either direction) by my server.





I agree with you.

But the reality is that a large number of legit senders will 
use the recipient or some other valid user in your domain as 
the envelope sender.


It's perfectly fine for you to have a policy that doesn't 
allow this, but be aware that there are still some babies in 
that bathwater.



That particular Postfix directive was created for some reason, so 
somebody, somewhere must agree.  Anyway, bottom line, it is my server.  
I try to protect my small number of users from the outside world (and 
themselves) as best I can.  If they don't like my policy, they can find 
another place to put their mail.  Others may not be lucky enough to be 
able to enforce such a policy, as the counter argument would be to find 
a less rigid admin. ;-)  What is 'acceptable' has to be determined on a 
site by site basis.  If it works for this site...great!  If it doesn't, 
then get rid of it.


I agree completely, I just want you to understand the 
implication of such a policy.  It may work well for you, it 
may not.  Depends greatly on your users and how much 
collateral damage they are collectively willing to accept, and 
your authority to enforce such a policy.





I hope that came off as a constructive, alternative vantage point rather 
than being argumentative.  :-)


-- DJ Lucas




Yes, that's what a discussion is all about.


--
Noel Jones

Re: FW: Help Needed with odd configuration...

[Noel Jones]

Spahn, Daniel wrote:

My setup is using the defaults, but the connection is so flaky that even pings 
don't return consistently. My current setup no longer delivers mail, but I get 
lots of timeout errors, and it looks like most messages end up in the defer 
queue. Any ideas? This is a highly political situation and the people 
responsible for fixing the problem will not work with me, yet I am responsible 
for the proper functioning of this email system. Anything that even has a 
slight chance of working will be greatly appreciated. To give a better picture 
of the setup, I have a professional-grade multifunction device that scans, 
faxes, prints, copies, etc.. It has a fixed IP on the LAN. Its scans go out to 
the postfix server, which is connected to a Cisco switch, Netgear firewall, and 
Cisco router/CSU/DSU. I have authentication turned on and it only accepts mail 
from the multifunction device. It's not a high-traffic system- it just 
occasionally has to send a few scans over email. I have administrat

ive access to the whole network, except the router/CSU/DSU (but any changes can 
be requested if needed). Any advice that can mitigate the poor line quality is 
appreciated.




You can tune postfix timeouts and retrys as described here:
http://www.postfix.org/TUNING_README.html#hammer
http://www.postfix.org/QSHAPE_README.html#queues

A very bad connection may drop before a message can get 
delivered.  If this happens often enough, it may make 
communication impossible.  SMTP requires that the connection 
stays up long enough for the message to be transmitted.


(thinking out loud (often gets me in trouble)):
Sounds as if you are transmitting to a fixed destination.  I 
wonder if a UDP-based VPN (such as OpenVPN) might give you a 
connection that drops less often.  It wouldn't help with the 
speed, but the drops are the big problem.  Hmm, since most 
VPNs support compression, maybe it could help with the speed.
You would need to have full control or significant cooperation 
at the far end for a VPN to be possible.


You also may be able to tune some of your operating system TCP 
parameters; increasing timeout and reducing max packet size 
would seem to be a starting place.  Check your OS docs for 
how; google for tuning TCP for lossy connections.


I don't have much experience with a bad connection, so anyone 
else feel free to jump in here...



--
Noel Jones

Re: Avoiding (trivial) spoofed "mail from"

[mouss]

DJ Lucas a écrit :
> Noel Jones wrote:
>>
>> Very likely there are other, better ways to combat this spam.  Look
>> for other traits you can use to reject it.
>>
> I am, by no means, anything even close to expert WRT the whole SMTP
> process, but, I do think that I can provide (or at least what I believe
> to be) a valid, albeit opinionated, counter argument.  See below.
>> some things to look for:
>> - client listed on some RBL
>> - client name that looks dynamic
>> - using your domain or IP as HELO
>> - unusual headers
>> - body text unlikely to be found in legit mail
>>
>> If that doesn't help, consider adding SpamAssassin and/or ClamAV.
> From my POV, this one check saves me a small few (100, 200?) DNS/RBL
> lookups per month and a few CPU cycles by not getting to header checks,
> body checks, and finally SA (which is probably the most expensive check
> in the stack, followed immediately by virus scanning).  I can probably
> parse my logs and give a real number, but it would seem insignificant to
> those running large servers.  It is my _choice_ to be as efficient as
> possible.
> 
> 
> Please correct me if I've made an invalid assumption (but do take notice
> of the "IMO" qualifier!)
> 
> I can find absolutely no reason to inadvertently mislead, or worse,
> intentionally deceive the recipient by forging the envelope sender's
> address.  In fact, the only reason I can see, is to intentionally
> deceive the recipient.  Is there any other reason?

some services use the "user" address because they believe that they are
acting on behalf of the user. examples include

- "send to a friend" (postcard, article, ...), "invite a friend",
"sell/buy/offer...", ...

- interfaces to mailing lists such as nabble

- user posting via his ISP/hotel/ relay.

- "classical" forwarding (.forward, aliases, ...)


SPF, DKIM and other anti-spam measures (such as the one discussed here)
are rendering these problematic. but you can't simply call this "poor
practice" or "deceptive practice".

so yes, you can establish a policy that states "nobody can use our
addresses in the envelope sender except from trusted networks or via
secure submission on port 587". but you must be aware of the
implications so that you can explain them to your users.

note that the envelope sender is not used to deceive the user, because
the user does not see it. it is generally used to fool "silly
whitelists" (some people whitelist their own domains, ...).

spammers who want to deceive the user forge the From: header.


> It is plain irresponsible, even if allowed by RFC.  Even more so given
> that most (all?) mail clients will honor the from header and display it,
> in big, bright, flashy, bold text, in a prominent location for the end
> user to see (and reply to).  Maybe I've missed something, but I really
> cannot find a good reason to allow it.  Even the BlackBerry example
> given above is an example of poor practice in my opinion, but it can be
> an ALLOWed exception if it is out of your control.
> 
> But that is all a matter of principal, not a technical reason.   The
> technical reason (minor increase in efficiency) was above, but I also
> provide one more weak technical argument.  Another possible (but pretty
> unlikely now days) side effect of allowing such message mangling to
> occur is that it could lead to backscatter if an intermediate server is
> mis-configured.  That is not my problem if it is 'properly' denied at
> the door and not allowed (either direction) by my server.
> 
> 


> That particular Postfix directive was created for some reason, so
> somebody, somewhere must agree.  Anyway, bottom line, it is my server. 
> I try to protect my small number of users from the outside world (and
> themselves) as best I can.  If they don't like my policy, they can find
> another place to put their mail.  Others may not be lucky enough to be
> able to enforce such a policy, as the counter argument would be to find
> a less rigid admin. ;-)  What is 'acceptable' has to be determined on a
> site by site basis.  If it works for this site...great!  If it doesn't,
> then get rid of it.
> 
> I hope that came off as a constructive, alternative vantage point rather
> than being argumentative.  :-)
> 

Re: limits

[Leonardo Rodrigues Magalhães]

polloxx escreveu:

Dear group,

We want to limit the number of mails a given IP address can send per
time unit (outbound).
What do you use to resolve this with a postfix server?
We want a flexible method were we can set the number of allowed mails
per time unit per IP address (in a SQL datbase).
  


   postfix cant do that alone. you'll need some policy server for that 
task. I would suggest policyd. It allows you to define throttling based 
on IP address and even on SASL-authenticated username. Data is stored in 
a MySQL database who can be managed with the web interface that comes 
with it or you can develop your own interface, even using the standard 
one as a template.


http://www.policyd.org/


--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
[EMAIL PROTECTED]
My SPAMTRAP, do not email it

Re: Limiting simultaneous transport usage

[Egoitz Aurrekoetxea]

Ok then, yep I had it configured that way in my mail systems... then the
result that having less or more process_limit set in master.cf for the smtp
or amavis daemon just could affect to the fact that the active queue can
become full (and mails automatically to go from incoming to deferred).. so
no errors should happen or other issues and postfix knows it only has X
proccess for a transport and that can't do more connections than that for
that transport. I haven't get almost problems because of this... but wanted
to ensure how this works.

Thanks a lot mates!!!

2008/12/2 Noel Jones <[EMAIL PROTECTED]>

> Egoitz Aurrekoetxea wrote:
>
>>
>> I have been talking about smtp client threads of postfix... but imagine
>> now (for understanding better...) amavis for example... you launch two
>> amavis processes as you specified in amavisd.conf. So if you set the
>> proccess_limit for amavis to 2 in master.cf  you
>> shouldn't never have a transport timeout or any kind of error for waiting
>> messages in active queue till amavis has a free proccess for accepting the
>> message? the only thing could happen is that the active queue reaches the
>> limit of messages in this queue and later are deferred instead of going to
>> active from incoming?
>>
>>
> See the README.postfix included with amavisd-new for details on setting up
> amavisd-new with postfix.
>
> - The number of postfix smtp processes feeding amavisd-new must be less
> than or equal to the number of amavisd-new processes running.
> - The number of postfix smtpd processes receiving mail from amavisd-new
> must be equal to or greater than the number of amavisd-new processes.
> - Amavisd-new must be able to process messages in less than postfix
> $smtp_data_done_timeout seconds, usually set in master.cf for the smtp
> feeding amavisd-new.
>
> If the above conditions are met, there should be no timeout errors
> regardless of the amount of mail queued, up to the limits of the machine.
>  All mail will stay in the active queue, up to $qmgr_message_active_limit.
>
> See the README.postfix included with amavisd-new for details on setting up
> amavisd-new with postfix.
>
> --
> Noel Jones
>

RE: FW: Help Needed with odd configuration...

[Spahn, Daniel]

My setup is using the defaults, but the connection is so flaky that even pings 
don't return consistently. My current setup no longer delivers mail, but I get 
lots of timeout errors, and it looks like most messages end up in the defer 
queue. Any ideas? This is a highly political situation and the people 
responsible for fixing the problem will not work with me, yet I am responsible 
for the proper functioning of this email system. Anything that even has a 
slight chance of working will be greatly appreciated. To give a better picture 
of the setup, I have a professional-grade multifunction device that scans, 
faxes, prints, copies, etc.. It has a fixed IP on the LAN. Its scans go out to 
the postfix server, which is connected to a Cisco switch, Netgear firewall, and 
Cisco router/CSU/DSU. I have authentication turned on and it only accepts mail 
from the multifunction device. It's not a high-traffic system- it just 
occasionally has to send a few scans over email. I have administrative access 
to the whole network, except the router/CSU/DSU (but any changes can be 
requested if needed). Any advice that can mitigate the poor line quality is 
appreciated.

Thanks!

Dan


-Original Message-
From: Noel Jones [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 02, 2008 5:06 PM
To: Spahn, Daniel
Cc: postfix-users@postfix.org
Subject: Re: FW: Help Needed with odd configuration...

Spahn, Daniel wrote:
> I am running A recent build of Postfix on a Gentoo server- I am pretty 
> sure it is about 3-4 months old. The problem I have is that the line the 
> mail is sent out on is buggy- I get lots of packet sequence errors, slow 
> speeds, etc. I need any advice I can get on configuring fault 
> tolerance-type options. This is a simple setup, and I am not talking 
> about clustering or failovers, simply how to set things so that things 
> that time out get retried a few minutes later, possibly several times to 
> mitigate the middle-of-the-day traffic rushes, as well as other network 
> spikes. Does anyone have any suggestions as to retry options, timeout 
> values? I am relatively inexperienced with MTA configuration, but I have 
> managed to get a couple of MTA's working in the past.  Thanks!
> 

The defaults should give pretty good performance with good 
tolerance for a flaky connection.

If you find the defaults insufficient, here are some relevant 
docs:
http://www.postfix.org/TUNING_README.html#hammer
http://www.postfix.org/QSHAPE_README.html#queues

Just as general info, if the connection stays active but is 
really slow (regardless if it's due to bandwidth or 
transmission errors) mail should keep flowing and the default 
settings should work well.
If the connection drops frequently, mail will be deferred and 
may have trouble ever getting delivered.  There isn't a good 
workaround in postfix (or any MTA I know of) for a connection 
that drops frequently.

-- 
Noel Jones

Re: Problems with backscaters and require authentication (Was: Digest of postfix-users list V1 #2211)

[mouss]

[EMAIL PROTECTED] a écrit :
>> --
>>
>> Date: Tue, 02 Dec 2008 14:50:21 +0100
>> From: mouss <[EMAIL PROTECTED]>
>> Subject: Re: Problems with backscaters and require authentication
>>
>> [EMAIL PROTECTED] a écrit :
>>> Hi,
>>>
>>> i have some problems with spammers and i would like to ask how to set
>>> postfix to validate sender email addresses only for our domains. Is
>>> there some way to do this?
>> what do you mean exactly by "validate"? check that the address exists?
>> you can use reject_unlisted_sender.
>>
>>> Other thing that i want to ask. I have this problem:
>>>
>>> i connect thru telnet to the smtp server and send email this way:
>>>
>>> helo myhostname.example.com
>>> mail from:[EMAIL PROTECTED]
>>> rcpt to:[EMAIL PROTECTED]
>>> data
>>> something here
>>> .
>>> quit
>>>
>>> mydomain.com is domain from the system.
>>>
>>> i'm able to send spam to this user, using the same email address in
>>> "mail from" field.
>>>
>>> Is there some way to protect my mailserver from this kind of things for
>>> our domains. If "mail from" use our domains (for example
>>> [EMAIL PROTECTED]), then to require authentication.
>>>
>>
>> smtpd_sender_login_maps =
>>  hash:/etc/postfix/sender_login
>>
>> smtpd_sender_restrictions =
>>  reject_sender_login_mismatch
>>
>>
>> http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
>>
>>
> 
> Hi, thanks for the reply. Yes i mean to check if sender exists, but only
> for our domains, not for all senders, because there are mail servers
> that reject this kind of checking.
> 
> I suppose that when i configure this way my system, it will not make
> problems with rest of senders, right?


yes, it's ok. use reject_unlisted_sender in smtpd restrictions.

you can use (with or without reject_unlisted_sender):
smtpd_reject_unlisted_sender = yes

Re: Digest of postfix-users list V1 #2211

[[EMAIL PROTECTED]]

> --
> 
> Date: Tue, 02 Dec 2008 14:50:21 +0100
> From: mouss <[EMAIL PROTECTED]>
> Subject: Re: Problems with backscaters and require authentication
> 
> [EMAIL PROTECTED] a écrit :
> > Hi,
> > 
> > i have some problems with spammers and i would like to ask how to set
> > postfix to validate sender email addresses only for our domains. Is
> > there some way to do this?
> 
> what do you mean exactly by "validate"? check that the address exists?
> you can use reject_unlisted_sender.
> 
> > 
> > Other thing that i want to ask. I have this problem:
> > 
> > i connect thru telnet to the smtp server and send email this way:
> > 
> > helo myhostname.example.com
> > mail from:[EMAIL PROTECTED]
> > rcpt to:[EMAIL PROTECTED]
> > data
> > something here
> > .
> > quit
> > 
> > mydomain.com is domain from the system.
> > 
> > i'm able to send spam to this user, using the same email address in
> > "mail from" field.
> > 
> > Is there some way to protect my mailserver from this kind of things for
> > our domains. If "mail from" use our domains (for example
> > [EMAIL PROTECTED]), then to require authentication.
> > 
> 
> 
> smtpd_sender_login_maps =
>   hash:/etc/postfix/sender_login
> 
> smtpd_sender_restrictions =
>   reject_sender_login_mismatch
> 
> 
> http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
> 
> 

Hi, thanks for the reply. Yes i mean to check if sender exists, but only
for our domains, not for all senders, because there are mail servers
that reject this kind of checking.

I suppose that when i configure this way my system, it will not make
problems with rest of senders, right?

limits

[polloxx]

Dear group,

We want to limit the number of mails a given IP address can send per
time unit (outbound).
What do you use to resolve this with a postfix server?
We want a flexible method were we can set the number of allowed mails
per time unit per IP address (in a SQL datbase).

Thx
P.