Re: Postfix - Timeout While Sending End of Data
DJ Lucas put forth on 2/15/2010 1:33 AM: > On 02/15/2010 01:30 AM, Stan Hoeppner wrote: >> DJ Lucas put forth on 2/15/2010 1:22 AM: >> >> >>> http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html >>> >> Never post links to information that requires a credit card in order to view >> it. >> I'm sure this breaks one if not many netiquette rules. ;) >> >> Surely there are many freely available texts with the relevant information >> that >> are just as good as this non-free text. >> >> > My apologies to the list. Didn't even think of that. In my (admittedly > weak) defense, you can scroll to the bottom of the page and get the > accepted solution and OPs responses without a CC for Experts Exchange. I can't get to it without entering a CC and starting a 30 day trial. The "bottom" of the page is white space. I see no options anywhere on the page to get at the info without signing up. This is kinda by design isn't it? No pay, no play? It's the whole point of the Experts Exchange website is it not? Due to your membership and cookies, even if you aren't logged in, you're probably still seeing a different page than those without a membership and prior cookies already on the the PC accessing the site. It's a no go. -- Stan
Re: Postfix - Timeout While Sending End of Data
On 02/15/2010 01:30 AM, Stan Hoeppner wrote: > DJ Lucas put forth on 2/15/2010 1:22 AM: > > >> http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html >> > Never post links to information that requires a credit card in order to view > it. > I'm sure this breaks one if not many netiquette rules. ;) > > Surely there are many freely available texts with the relevant information > that > are just as good as this non-free text. > > My apologies to the list. Didn't even think of that. In my (admittedly weak) defense, you can scroll to the bottom of the page and get the accepted solution and OPs responses without a CC for Experts Exchange. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean.
Re: Postfix - Timeout While Sending End of Data
DJ Lucas put forth on 2/15/2010 1:22 AM: > http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html Never post links to information that requires a credit card in order to view it. I'm sure this breaks one if not many netiquette rules. ;) Surely there are many freely available texts with the relevant information that are just as good as this non-free text. -- Stan
Re: Postfix - Timeout While Sending End of Data
On 02/14/2010 10:17 PM, Jafaruddin Lie wrote:
>
> We do have a CISCO ASA 5520 that the outgoing mailserver sits behind,
> and I have done the no fixup protocol on the box to no avail.
> I have also enabled ICMP from that box to our internal mail server,
> and ping works so I figure the ICMP NO-FRAGMENT wouldn't be an issue
> here now.
>
It sounds as though the issue surfaced about the same time the new
security device came into play. If so, it might help to make that
absolutely clear to everyone who reads this thread. Is this the only
change in the environment? From what you've said above, it sounds like
you're on the right track. Only thing I noticed is that you mentioned
fixup (PIX) and not inspect (ASA). I don't have an ASA in front of me
ATM (and honestly, I'm not all that good with them anyway), however
something 'like' the following commands should get you to the right
place if you don't have access to ASDM (assuming you haven't changed too
much in the default configuration). There are plenty of examples all
over the net if you use the correct search terms. Obviously, you should
do a 'show run' to make sure my second assumption is correct (and that
this could even be the problem).
{{{
policy-map global_policy
class inspection_default
no inspect esmtp
}}}
Don't forget to write, else it'll be gone on reboot if it works. Sorry,
done that a couple of times myself, though I always dump my configs. A
friendly reminder never hurts either way.
BTW, here is a better example than the Cisco docs (IMO), probably should
have just linked to there in the first place instead of the above
gibberish. Oh well.
http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_24438893.html
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
Postfix - Timeout While Sending End of Data
Our Postfix server (RHEL 4, stock-standard RPM) is playing up at the moment. The mail server is our outgoing mail server (on the DMZ), and I noticed that since last weekend we're having this issue: A lot of the mails generated by our web applications (and manually, may I add) were being queued up with this error message: delivery temporarily suspended: conversation with MAILSERVER timed out while sending end of data -- message may be sent more than once. It happens to emails sent to all domains. Some are delivered eventually, some seems to be stuck in the queue, and then there are some others that were delivered immediately. Restarting the service doesn't seem to help. Nothing on maillog or message log or error log. We do have a CISCO ASA 5520 that the outgoing mailserver sits behind, and I have done the no fixup protocol on the box to no avail. I have also enabled ICMP from that box to our internal mail server, and ping works so I figure the ICMP NO-FRAGMENT wouldn't be an issue here now. Help? -- Registered Linux user no. 384430
Re: suppress NDRs from spoofed sender
On Tuesday 19 January 2010, Ansgar Wiechers wrote: > On 2010-01-18 David Koski wrote: > > My mail server has been getting a fair amount of spam hits that have > > been rejected but the sender address is spoofed with the recipient's > > address. This generates an NDR to the recipient with the spam. I > > would like to suppress NDRs of this kind but not legitimate NDRs. > > What I'm doing is this: > > - store a hash of From:, To: and Date: header of all outgoing mail > - accept all bounces that include From:, To: and Date: headers whose > hash matches a stored hash > - remove stored hashes older than 4 days > > This method does lead to rejection of valid bounces that don't include > the above mentioned headers. However, I consider those bounces useless > anyway. How about something more simple: test for From: is the same as To: and is from MAILER-DAEMON: grep "^From:.*" "$test" \ && grep "Return-Path:.*" "$test" \ && grep "^To:.*" "$test" ..where "$test" is the email file to scan. But can this be done with Postfix? Regards, David Koski da...@kosmosisland.com
Re: how to specify a "default key" in access(5)
Wietse Venema put forth on 2/14/2010 12:52 PM: > regexp:/etc/postfix/recipients.pcre ^^ Wietse is this a typo or am I about to learn something new about regexp/pcre interchangeability/compatibility in Postfix? I'm assuming in the example above that the .pcre file actually contains pcre syntax, not regexp syntax. -- Stan
Re: how to specify a "default key" in access(5)
On Sun, 2010-02-14 at 23:44 +0100, mouss wrote: > Stefan Palme a écrit : > >> check_recipient_access hash:/etc/postfix/recipients > >> check_recipient_access pcre:/etc/postfix/recipients_default > >> > >> // REJECT rejected for testing purposes > > > > Thanks for the hint. But the content of "recipients_default" must > > also be stored in LDAP (because some admin with LDAP access privileges > > will define the default behaviour), so I can not use regular expression > > lookups, but only the lookups as defined by the access(5) syntax. > > > > if it's in ldap, then do it in ldap instead of pcre. make your ldap > query return the "default behaviour" whatever the key is. Something like this? check_recipient_access ldap:/etc/postfix/recipients.cf check_recipient_access ldap:/etc/postfix/recipients_default.cf with /etc/postfix/recipients_default.cf: search_base = ou=postfix,dc=example,dc=com query_filter = (&(objectClass=postfixConfiguration)(cn=DEFAULT_BEHAVIOUR)) Nice idea... Have to take a look at this. Thanks a lot! -stefan-
Re: how to specify a "default key" in access(5)
Stefan Palme a écrit : >> check_recipient_access hash:/etc/postfix/recipients >> check_recipient_access pcre:/etc/postfix/recipients_default >> >> // REJECT rejected for testing purposes > > Thanks for the hint. But the content of "recipients_default" must > also be stored in LDAP (because some admin with LDAP access privileges > will define the default behaviour), so I can not use regular expression > lookups, but only the lookups as defined by the access(5) syntax. > if it's in ldap, then do it in ldap instead of pcre. make your ldap query return the "default behaviour" whatever the key is.
Re: content_filter .vs. transport_maps
Stefan Palme: > On Sun, 2010-02-14 at 14:21 -0500, Wietse Venema wrote: > > content_filter and FILTER have precedence over all routing mechanisms > > in Postfix including transport_maps, relayhost, address classes, etc. > > Ok, but if I have a very simple setup without any per-whatever > transport_maps, relayhost, etc. it does not really make any > difference if I use a simple transport_map or the content_filter > declaration? These mechanisms not only have different names, but they also have different behaviors. - The meaning of empty transport or nexthop fields is different, and this difference depends on Postfix versions. - Running "postsuper -r" will remove the content filter override. There may be other differences. I suggest that you study the documentation and determine if those differences matter to you. Wietse
Re: content_filter .vs. transport_maps
On Sun, 2010-02-14 at 14:21 -0500, Wietse Venema wrote: > content_filter and FILTER have precedence over all routing mechanisms > in Postfix including transport_maps, relayhost, address classes, etc. Ok, but if I have a very simple setup without any per-whatever transport_maps, relayhost, etc. it does not really make any difference if I use a simple transport_map or the content_filter declaration? Regards -stefan-
Re: content_filter .vs. transport_maps
Stefan Palme: > Hi, > > Is the effect of > > content_filter = smtp:[127.0.0.1]:10025 > > the same as > > transport_maps = hash:/etc/postfix/transports > > /etc/postfix/transports: > *smtp:[127.0.0.1]:10025 content_filter and FILTER have precedence over all routing mechanisms in Postfix including transport_maps, relayhost, address classes, etc. Wietse
Re: how to specify a "default key" in access(5)
Geert Hendrickx: > On Sun, Feb 14, 2010 at 07:42:58PM +0100, Stefan Palme wrote: > > > > > check_recipient_access hash:/etc/postfix/recipients > > > check_recipient_access pcre:/etc/postfix/recipients_default > > > > > > // REJECT rejected for testing purposes > > > > Thanks for the hint. But the content of "recipients_default" must also be > > stored in LDAP (because some admin with LDAP access privileges will > > define the default behaviour), so I can not use regular expression > > lookups, but only the lookups as defined by the access(5) syntax. > > > > If all recipients are in the same domain, you can specify a catch-all > address with the domain-default action: > > > us...@example.com action1 > us...@example.com action2 > @example.com REJECT foobar Minor correction: us...@example.com action1 us...@example.com action2 example.com REJECT foobar (the @domain notation is used mainly in address rewriting maps). Wietse
Re: how to specify a "default key" in access(5)
On Sun, Feb 14, 2010 at 07:42:58PM +0100, Stefan Palme wrote: > > > check_recipient_access hash:/etc/postfix/recipients > > check_recipient_access pcre:/etc/postfix/recipients_default > > > > // REJECT rejected for testing purposes > > Thanks for the hint. But the content of "recipients_default" must also be > stored in LDAP (because some admin with LDAP access privileges will > define the default behaviour), so I can not use regular expression > lookups, but only the lookups as defined by the access(5) syntax. If all recipients are in the same domain, you can specify a catch-all address with the domain-default action: us...@example.com action1 us...@example.com action2 @example.comREJECT foobar Geert -- Geert Hendrickx -=- g...@telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
content_filter .vs. transport_maps
Hi, Is the effect of content_filter = smtp:[127.0.0.1]:10025 the same as transport_maps = hash:/etc/postfix/transports /etc/postfix/transports: *smtp:[127.0.0.1]:10025 ? Thanks and regards -stefan-
Re: how to specify a "default key" in access(5)
Stefan Palme: > Hi, > > I guess I'm just temporarily blind, but I can't find a solution. > I have a smtpd_recipient_restriction like this: > > ..., check_recipient_access hash:/etc/postfix/recipients, permit /etc/postfix/main.cf: ... check_recipient_access hash:/etc/postfix/recipients regexp:/etc/postfix/recipients.pcre ... /etc/postfix/recipients.pcre: /./ whatever Wietse
Re: how to specify a "default key" in access(5)
> check_recipient_access hash:/etc/postfix/recipients > check_recipient_access pcre:/etc/postfix/recipients_default > > // REJECT rejected for testing purposes Thanks for the hint. But the content of "recipients_default" must also be stored in LDAP (because some admin with LDAP access privileges will define the default behaviour), so I can not use regular expression lookups, but only the lookups as defined by the access(5) syntax. -stefan-
Re: how to specify a "default key" in access(5)
* Stefan Palme : > Hi, > > I guess I'm just temporarily blind, but I can't find a solution. > I have a smtpd_recipient_restriction like this: > > ..., check_recipient_access hash:/etc/postfix/recipients, permit check_recipient_access hash:/etc/postfix/recipients check_recipient_access pcre:/etc/postfix/recipients_default // REJECT rejected for testing purposes -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
how to specify a "default key" in access(5)
Hi,
I guess I'm just temporarily blind, but I can't find a solution.
I have a smtpd_recipient_restriction like this:
..., check_recipient_access hash:/etc/postfix/recipients, permit
with /etc/postfix/recipients:
us...@example.com REJECT don't use this!
us...@example.net DEFER some other reason
. REJECT rejected for testing purposes
(This is just for some tests, so don't mind about how useful
this may be ;-)
The last entry in this file seems not to work - all recipient
addresses (except us...@example.com and us...@example.net) fall
through this test, so that the next rule in recipient_restrictions
("permit") applies to them.
Is there a way to define a kind of "fallback lookup pattern"?
[Some background information: this "recipients" file will later
be converted into an LDAP lookup. For this reason, the following
will NOT be a solution for me:
smtpd_recipient_restrictions =
...,
check_recipient_access ldap:/etc/postfix/recipients.cf,
reject rejected for testing purposes,
Because the person with access to the LDAP tree containing the
recipients information must also be able to define the default
behaviour for all the not explicitly specified recipient addresses].
Regards
-stefan-
Postfix 2.7.0 stable release available
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.7.0.html] Postfix stable release 2.7.0 is available. For the past several releases, the focus has moved towards improving the code and documentation, and updating the system for changing environments. - Improved before-queue content filter performance. With "smtpd_proxy_options = speed_adjust", the Postfix SMTP server receives the entire message before it connects to a before-queue content filter. Typically, this allows Postfix to handle the same mail load with fewer content filter processes. - Improved address verification performance. The verify database is now persistent by default, and it is automatically cleaned periodically, Under overload conditions, the Postfix SMTP server no longer waits up to 6 seconds for an address probe to complete. - Support for reputation management based on the local SMTP client IP address. This is typically implemented with "FILTER transportname:" actions in access maps or header/body checks, and mail delivery transports in master.cf with unique smtp_bind_address values. - The postscreen daemon (a zombie-blocker in front of Postfix) is still too rough for a stable release, and will be made "mature" in the Postfix 2.8 development cycle (however you can use Postfix 2.7 with the Postfix 2.8 postscreen and dnsblog executables and master.cf configuration; this code has already proven itself). No functionality has been removed, but it is a good idea to review the RELEASE_NOTES file for the usual minor incompatibilities or limitations. You can find Postfix version 2.7.0 at the mirrors listed at http://www.postfix.org/ The same code is also available as Postfix snapshot 2.8-20100213. Updated versions of Postfix version 2.6, 2.5 and perhaps earlier will be released with the same fixes that were already included with Postfix versions 2.7 and 2.8. Wietse
Re: Restrictions on localhost
On Sat, Feb 13, 2010 at 11:36:22AM -0500, Alex wrote: > I have a Linux server running an older version of postfix and > webmail for users to send mail. Since localhost is trusted in > $mynetworks, a connection from there can send mail to any > recipient. Since squirrelmail connects directly to localhost, > any mail that it sends is authorized. Squirrelmail might not be connecting to localhost at all. The more likely default is that it uses sendmail(1) submission. That is an all-or-nothing proposition; sendmail either takes what a given user (in this case, your Web server's process UID) gives it, or it takes nothing at all. See: http://www.postfix.org/postconf.5.html#authorized_submit_users http://www.postfix.org/sendmail.1.html > How can I add restrictions on localhost, despite it being > authorized, from sending mail as certain users or to certain > recipients? It is probable that the eventual solution to whatever problem you encountered will be found within Squirrelmail, off topic here. You could force the use of SMTP, and force authentication, and use restriction classes and smtpd_sender_login_maps. I do not know if Squirrelmail is capable of per-user AUTH. The Postfix part of it is documented: http://www.postfix.org/SASL_README.html http://www.postfix.org/RESTRICTION_CLASS_README.html http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Restrictions on localhost
On Sat, 13 Feb 2010, Alex wrote: > I have a Linux server running an older version of postfix and webmail > for users to send mail. Since localhost is trusted in $mynetworks, a > connection from there can send mail to any recipient. Since > squirrelmail connects directly to localhost, any mail that it sends is > authorized. How can I add restrictions on localhost, despite it being > authorized, from sending mail as certain users or to certain > recipients? Enforce the restrictions before you permit_mynetworks. -- Sahil Tandon
Re: Google generating it's own reject codes?
On Sat, 13 Feb 2010, LuKreme wrote: > On 13-Feb-2010, at 15:15, Wietse Venema wrote: > > > > You missed a whole paragraph in my response: > > No, I just didn't respond to it as there didn't seem to be any need. Postfix does not log every single status code it sends to SMTP clients; that was the point of Wietse's paragraph and should mitigate your "surprise" in not seeing 552 in your logs. -- Sahil Tandon
