Le 28/09/2010 23:44, motty.cruz a écrit :
> Hello,
> When a client has a typo in the recipient email address it takes 5 days for
> my SMTP server to notify that the user does not exist or was unable to
> deliver email.

No. you are wrong. when you mistype an address, you get an immediate
error stating "doesn't exist". try sending mail to joe@... and
tell me when you get the error. if it takes you 5 days to see an error
that was sent 5 days before, you have a serious issue.


> Any idea where to change the option to make it more reliable.

Le 29/09/2010 23:17, Shane Dittmar a écrit :
> Hey,
>
> I'm baffled by yet another problem. I installed Amavis, performed
> necessary master.cf, amavis conf.d, and main.cf changes, and launched
> the service.
>
> However, it seems that Amavis is being denied by the Postfix SMTPD
> listening on 10025 when it attempts to reinject the mail. When I
> telnet to 127.0.0.1:10025 (on the server), I am immediately
> disconnected ("Connection closed by foreign host.") The log output
> generated by this connection looks like this:
>
> Sep 29 16:59:45 shanedittmar postfix/smtpd[10141]: fatal: unexpected
> command-line argument: reject
> Sep 29 16:59:46 shanedittmar postfix/master[26160]: warning: process
> /usr/lib/postfix/smtpd pid 10141 exit status 1
> Sep 29 16:59:46 shanedittmar postfix/master[26160]: warning:
> /usr/lib/postfix/smtpd: bad command startup -- throttling
>
> This is the configuration I added to master.cf to creat the second SMTPD.
>
> amavis      unix    -       -       -       -       2       smtp
>   -o smtp_data_done_timeout=1200
>   -o smtp_send_xforward_command=yes
>   -o disable_dns_lookups=yes
>   -o max_use=20
> 127.0.0.1:10025 inet n - n - - smtpd
>   -o content_filter=
>   -o local_recipient_maps=
>   -o relay_recipient_maps=
>   -o smtpd_restriction_classes=
>   -o smtpd_delay_reject=no
>   -o smtpd_client_restrictions=permit_mynetworks, reject


space before "reject".
>   [snip]

Le Wed 29/09/2010, mouss disait
>  Le 28/09/2010 23:44, motty.cruz a écrit :
> >Hello,
> >When a client has a typo in the recipient email address it takes 5 days for
> >my SMTP server to notify that the user does not exist or was unable to
> >deliver email.
>
> No. you are wrong. when you mistype an address, you get an immediate
> error stating "doesn't exist". try sending mail to joe@...
> and tell me when you get the error. if it takes you 5 days to see an
> error that was sent 5 days before, you have a serious issue.
>
>
> >Any idea where to change the option to make it more reliable.


It might be that the receiving server is set up to return a temporary error code
for unexistent address

--
Erwan

Wow, that was a stupid error. (I probably misssed it because I'm blind)

Thanks!

On 9/29/10, mouss <mouss@...> wrote:
>   Le 29/09/2010 23:17, Shane Dittmar a écrit :
>> Hey,
>>
>> I'm baffled by yet another problem. I installed Amavis, performed
>> necessary master.cf, amavis conf.d, and main.cf changes, and launched
>> the service.
>>
>> However, it seems that Amavis is being denied by the Postfix SMTPD
>> listening on 10025 when it attempts to reinject the mail. When I
>> telnet to 127.0.0.1:10025 (on the server), I am immediately
>> disconnected ("Connection closed by foreign host.") The log output
>> generated by this connection looks like this:
>>
>> Sep 29 16:59:45 shanedittmar postfix/smtpd[10141]: fatal: unexpected
>> command-line argument: reject
>> Sep 29 16:59:46 shanedittmar postfix/master[26160]: warning: process
>> /usr/lib/postfix/smtpd pid 10141 exit status 1
>> Sep 29 16:59:46 shanedittmar postfix/master[26160]: warning:
>> /usr/lib/postfix/smtpd: bad command startup -- throttling
>>
>> This is the configuration I added to master.cf to creat the second SMTPD.
>>
>> amavis      unix    -       -       -       -       2       smtp
>>   -o smtp_data_done_timeout=1200
>>   -o smtp_send_xforward_command=yes
>>   -o disable_dns_lookups=yes
>>   -o max_use=20
>> 127.0.0.1:10025 inet n - n - - smtpd
>>   -o content_filter=
>>   -o local_recipient_maps=
>>   -o relay_recipient_maps=
>>   -o smtpd_restriction_classes=
>>   -o smtpd_delay_reject=no
>>   -o smtpd_client_restrictions=permit_mynetworks, reject
>
>
> space before "reject".
>>   [snip]
>
>


--
-Shane
Website: http://www.blind-geek.com
AIM: inhaddict
MSN: shane@...
Skype: chatter8712
Twitter: @shanervr

Michal Bruncko put forth on 9/29/2010 10:57 AM:
> Thank you for hint. It seems that this soft is also included in my
> distro repository (fedora), perfect! :)
>
> michal

You're welcome.  I've never used milter-greylist, so I can't attest to
its performance, reliability, ease of use, etc, but it does have the one
feature you want.  Let us know how it works out for you.

--
Stan



> On 29. 9. 2010 11:36, Stan Hoeppner wrote:
>> Michal Bruncko put forth on 9/29/2010 4:03 AM:
>>
>>> I mean automatically accepted by postfix, but not automatically
>>> forwarded to mailboxes. My idea lies on principle, that if sender have
>>> valid SPF record, there is no need to greylist (and delaying mail
>>> receiving), but...  SPF and greylisting are only one part of mail
>>> checking (checking directly in smtpd_recipient_restrictions in postfix).
>>> I am using amavis with SA, viruschecking and next supplementary tests
>>> (razor, ddc and so on)  for scoring mails and then forwarding through
>>> MDA to mailboxes.
>>
>> milter-greylist will do exactly what you want.
>>
>> http://hcpnet.free.fr/milter-greylist/
>>
>> "SPF records
>>
>> Starting with version 1.1.3, milter-greylist is able to use libspf_alt
>> to check SPF records. SPF records are DNS objects that tell the whole
>> Internet which server(s) can legally send e-mail from a domain.
>>
>> Using SPF records, milter-greylist will avoid greylisting any mail that
>> comes from an SPF-compliant server. This feature is optionnal and
>> requires libspf_alt
>>
>> Starting with 1.1.10, libspf (James Couzens's version) is also
>> supported. libpsf2 is supported starting with version 1.7.2."
>>
>>
>

Kris Deugau put forth on 9/29/2010 2:33 PM:

> Hmm, no, less than 100M:
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 28776 rbldns    20   0 81740  65m  700 S    0  3.3 118:49.42 rbldnsd

I was going by information I received from another list.  I don't use
the data feed service.  Does this include the CBL data set within Zen?
I would make an educated guess that the size of the CBL data set would
be over 100MB alone.  25 million 32bit IP addresses (4 bytes) would be
100MB, if my math is correct.  25 million bot infected hosts around the
world seems like a very conservative estimate.

> And this with a modest local blacklist loaded in as well.  The on-disk
> files for all of the lists total just over 100M.  We just run the
> Spamhaus data on a non-public zone on our general resolvers (running
> dnscache) and we have yet to see any latency problems.

With fast resolvers and local GigE, performance should be fine for many
sites as you state.  It's also easier to manage than running rbldnsd on
each MX as you have a single update point.  I know of one site,
coincidentally also in Canada, running two MX hosts.  Each receives,
IIRC, on an average day, ~50 million connection attempts, 100 million
total.  This is nowhere near the numbers of a good sized ISP obviously
and tiny compared to a gorilla such as Gmail.

The OP runs rbldnsd on each MX, with the full Spamhaus zones minus the
CBL.  Also incorporated into the rbldnsd instances are extensive local
block lists, the Enemies List, the CBL data, and some other mirrored
dnsbl data.  This may be the multi gigabyte setup I was thinking of,
which isn't just Spamhaus zones.  Interestingly, this site doesn't
reject any spam due to any hits against any list.  After DATA, a 55x is
returned to the client, but the entire message is saved for further anti
spam heuristics processing.  It's one of the most elaborate setups I've
heard of.  Then again, some of the most elaborate setups _no one_ will
probably hear about. ;)

> The biggest sysadmin/network costs for the rsync service are in
> configuration (may need extra scripting to distribute the data to
> multiple rbldnsd instances, depending on how you want to arrange your
> DNS services - otherwise, it's "set up once, let it run") and update
> bandwidth - currently they provide a script intended to be called once a
> minute to update the zone data source files.

Yeah, running the Spamhaus zones on local rbldnsd instances on each MX
would require some distribution magic, as you state.  Never done this
myself.  I'd be more inclined to go the route you've taken, if I were
ever in a position to manage such a thing.

--
Stan

Hi,

I have a problem that the smtpd_proxy_filter option has higher priority than a
FILTER setting in an access table:

Sep 30 12:33:04 mx0 postfix/smtpd[5250]: warning: access table
cidr:/etc/postfix/maps/client_access.cidr: with smtpd_proxy_filter specified,
action FILTER is unavailable

What I need is a mechanism to re-route a mail to a different policy-bank in
amavis, if a MTA-client is found in a whitelist:

smtp       inet  n       -       -       -       1       postscreen
smtpd      pass  -       -       -       -       10      smtpd
     -o smtp_bind_address=127.0.0.1
     -o smtpd_proxy_filter=[127.0.0.1]:10024
     -o smtpd_client_connection_rate_limit=5
     -o smtpd_client_message_rate_limit=5
     -o smtpd_client_recipient_rate_limit=30
dnsblog   unix  -        -      -       -       0       dnsblog
...


In main.cf:

smtpd_recipient_restrictions =
     ...
     check_client_access cidr:/etc/postfix/maps/client_access.cidr,
     ...


/etc/postfix/maps/client_access.cidr:
# Whitelisting
193.239.107.22  FILTER lmtp-amavis:[::1]:10027


amavis:

$interface_policy{'10027'} = 'WHITELIST';
$policy_bank{'WHITELIST'} = {
   allow_disclaimers               => 1,
   bypass_spam_checks_maps         => [1],                                  # I
want to disable spam-checks for SWL and DWL
   terminate_dsn_on_notify_success => 0,
};


This test here is a pre-prototype for thinking about coding a policy-service
that respects swl.spamhaus.org and dwl.spamhaus.org. Yet I do not know how to
_really_ whitelist candidates on these lists. So I took my friend Uwe's MTA for
a first test of whitelisting.

Also the question for postscreen: Does it allow negative scoring of dnsbl? So I
could use that lookup mechanism, too. At the moment I try to negative score
whitelists in policyd-weight.

This all is not so easy for me right now :-)

Best regards
Christian


---
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

On 9/30/2010 8:16 AM, Cimoni Enwis Ogwujiakwu wrote:
> Hello,
> I have setup a postfix server for scanning mails for spam relayed
> through it and I have redirected all port 25 traffic through it from my
> firewall but when I try sending mails through
> telnet for example smtp.gmail.com 25
>  I still get through without seeing any transcation on the postfix
> server and no scanning by the spam assassin.
> What I am getting wrong here.
>

Do you mean you are wanting to scan even outbound email?  If so, hitting
smtp.gmail.com 25 directly will circumvent that.

You would want to have your clients send their outbound email through
your postfix server and configure it to scan outbound mail.

-Matt

On Sep 30, 2010, at 8:16 AM, Cimoni Enwis Ogwujiakwu wrote:

> Hello,
> I have setup a postfix server for scanning mails for spam relayed through it
and I have redirected all port 25 traffic through it from my firewall but when I
try sending mails through
> telnet for example smtp.gmail.com 25
>  I still get through without seeing any transcation on the postfix server and
no scanning by the spam assassin.
> What I am getting wrong here.
>
>

postconf -n

SA doesn't run on port 25 usually. in main.cf you should have a content_filter
statement.

eg;
content_filter = smtp-amavis:[127.0.0.1]:10024

Today I found a interesting problem regarding postscreen and a popular
(?) address verification milter in sendmail

From my logs:

Sep 30 15:23:53 mail postfix/postscreen[21955]: NOQUEUE: reject: RCPT from
[192.109.31.12]: 550 5.5.1 Protocol error; from=<>, to=<valid.user@...>,
proto=SMTP, helo=<mail.embl-hamburg.de>
Sep 30 15:23:53 mail postfix/postscreen[21955]: NOQUEUE: reject: RCPT from
[192.109.31.12]: 550 5.5.1 Protocol error; from=<postmaster@...>,
to=<valid.user@...>, proto=SMTP, helo=<mail.embl-hamburg.de>

The idea of using two different senders is very nice per se, but it
seems that the milter is triggering some check within postscreen

192.109.31.12 is running:
220 mail.EMBL-Hamburg.DE ESMTP Sendmail 8.13.8/8.13.8/Debian-2; Thu, 30 Sep 2010
16:06:22 +0200; (No UCE/UBE) logging access from:
mail.charite.de(OK)-mail.charite.de [141.42.202.200]

I cannot say anything about the milter in use. A prior bug report of
mine against "Smart Sendmail Filters"

https://sourceforge.net/tracker/?func=detail&aid=2815073&group_id=131540&atid=72\
1356

"The sender address verification sends an HELO *before* the receiving
server emits its SMTP banner. Thus, the probe (or the whole server)
gets classified as "earlytalker" and (in my case) gets disconnected
immediately. The verification probes must adhere to the SMTP protocol,
otherwise they're worthless because they're generating false negatives."

I have no doubt that the error is NOT in Postfix, but what exactly
does the log excerpt mean? Which protocol error exactly is postscreen
complaining about?

--
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.hildebrandt@... | http://www.charite.de

Hello When I configured client to send mails via postfix server, everything works fine but I do not want the clients to enter the postfix server address when sending mails.

I still want them to point to their respective smtp server like smtp.example.com and be redirected on the firewall through the postfix server,

On Thu, Sep 30, 2010 at 04:18:47PM +0200, Ralf Hildebrandt wrote:

> I cannot say anything about the milter in use. A prior bug report of
> mine against "Smart Sendmail Filters"
>
>
https://sourceforge.net/tracker/?func=detail&aid=2815073&group_id=131540&atid=72\
1356
>
> "The sender address verification sends an HELO *before* the receiving
> server emits its SMTP banner. Thus, the probe (or the whole server)
> gets classified as "earlytalker" and (in my case) gets disconnected
> immediately. The verification probes must adhere to the SMTP protocol,
> otherwise they're worthless because they're generating false negatives."
>
> I have no doubt that the error is NOT in Postfix, but what exactly
> does the log excerpt mean? Which protocol error exactly is postscreen
> complaining about?

Do you have a tcpdump capture? From the above it sounds like HELO is
sent before the 220 banner. That's a protocol error.

--
	 Viktor.

On Thu, Sep 30, 2010 at 12:48:19PM +0200, Christian R??ner wrote:

> I have a problem that the smtpd_proxy_filter option has higher priority
> than a FILTER setting in an access table:

No, it does not. Rather, these are completely separate mechanisms, and
there is no reason to expect post-queue FILTER directives to influence
the pre-queue proxy, or conversely instantiation of a pre-queue filter
to influence post-queue FILTER directives.

> Sep 30 12:33:04 mx0 postfix/smtpd[5250]: warning: access table
> cidr:/etc/postfix/maps/client_access.cidr: with smtpd_proxy_filter
> specified, action FILTER is unavailable

It is not possible for the SMTP server that is in-front of the pre-queue
filter to add "FILTER" records to the Postfix queue-file, as no queue-file
is generated. The message is sent via SMTP to the pre-queue proxy, there
are is no "FILTER" verb in SMTP.

The FILTER directive can only be set by the SMTP server that is *behind*
the pre-queue proxy. The front-end SMTP server can add headers, which
you could use downstream to (carefully avoding allowing outside parties
specify the FILTER transport or nexthop) selectively trigger a FILTER
in the SMTP server that is back-end SMTP server.

--
	 Viktor.

* Victor Duchovni <Victor.Duchovni@...>:

> Do you have a tcpdump capture? From the above it sounds like HELO is
> sent before the 220 banner. That's a protocol error.

No tcpdump, but I have this:
Sep 30 15:23:53 mail postfix/postscreen[21955]: CONNECT from 192.109.31.12
Sep 30 15:23:53 mail postfix/postscreen[21955]: PREGREET 27 after 0.01 from
192.109.31.12: HELO mail.embl-hamburg.de??
Sep 30 15:23:53 mail postfix/postscreen[21955]: NOQUEUE: reject: RCPT from
[192.109.31.12]: 550 5.5.1 Protocol error; from=<>,
to=<valid.recipient@...>, proto=SMTP, helo=<mail.embl-hamburg.de>
Sep 30 15:23:53 mail postfix/postscreen[21955]: NOQUEUE: reject: RCPT from
[192.109.31.12]: 550 5.5.1 Protocol error;
from=<postmaster@...>, to=<valid.recipient@...>, proto=SMTP,
helo=<mail.embl-hamburg.de>
Sep 30 15:23:53 mail postfix/postscreen[21955]: DISCONNECT 192.109.31.12
Sep 30 15:53:56 mail postfix/postscreen[10531]: CONNECT from 192.109.31.12
Sep 30 15:53:56 mail postfix/postscreen[10531]: WHITELISTED 192.109.31.12
Sep 30 15:53:56 mail postfix/postscreen[10531]: PASS OLD 192.109.31.12
Sep 30 15:53:56 mail postfix/smtpd[10563]: connect from
mail.EMBL-Hamburg.DE[192.109.31.12]
Sep 30 15:53:56 mail postfix/smtpd[10563]: NOQUEUE:
client=mail.EMBL-Hamburg.DE[192.109.31.12]
Sep 30 15:53:56 mail postfix/smtpd[10563]: disconnect from
mail.EMBL-Hamburg.DE[192.109.31.12]

which seems to back our both assumptions.

--
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.hildebrandt@... | http://www.charite.de

On Thu, Sep 30, 2010 at 11:07:23AM -0700, Claus Assmann wrote:

> On Thu, Sep 30, 2010, Victor Duchovni wrote:
>
> > Do you have a tcpdump capture? From the above it sounds like HELO is
> > sent before the 220 banner. That's a protocol error.
>
> Is it?
>
> 4.3.1 Sequencing Overview
> ...
>    One important reply is the connection greeting.  Normally, a receiver
>    will send a 220 "Service ready" reply when the connection is
>    completed.  The sender SHOULD wait for this greeting message before
>    sending any commands.
>
> So this is "just" a SHOULD, not a MUST, hence not a protocol error
> per se. Any real MTA will obey the SHOULD requirement of course.

And how at that point does the SMTP client not get out sync with the SMTP
server? If it does not wait for 220, it will misread the banner as the
HELO response! Unless you are suggesting that pipelining is implicitly
allowed in that context.

You left out the first part of 4.3.1:

     4.3.1.  Sequencing Overview

        The communication between the sender and receiver is an alternating
        dialogue, controlled by the sender.  As such, the sender issues a
        command and the receiver responds with a reply.  Unless other
        arrangements are negotiated through service extensions, the sender
        MUST wait for this response before sending further commands.  One
        important reply is the connection greeting.  Normally, a receiver
        will send a 220 "Service ready" reply when the connection is
        completed.  The sender SHOULD wait for this greeting message before
        sending any commands.

The half-duplex nature of the protocol is clearly stated, and the fact
that exceptions to this are only allowed via service extensions. The
"SHOULD" here is unfortunate. I can see a client sending "QUIT" before
the banner if a timeout elapses, but proceeding to HELO before 220 is
not a reasonable interpretation of 4.3.1.

Of course a client can at any time abandon the connection and send a
premature "QUIT" (if not in the middle of data transfer). So the special
case treatment of 220 in 4.3.1 is a specification bug.

--
	 Viktor.

On Thu, Sep 30, 2010, Victor Duchovni wrote:

> Do you have a tcpdump capture? From the above it sounds like HELO is
> sent before the 220 banner. That's a protocol error.

Is it?

4.3.1 Sequencing Overview
...
    One important reply is the connection greeting.  Normally, a receiver
    will send a 220 "Service ready" reply when the connection is
    completed.  The sender SHOULD wait for this greeting message before
    sending any commands.

So this is "just" a SHOULD, not a MUST, hence not a protocol error
per se. Any real MTA will obey the SHOULD requirement of course.

* Len Conrad <lconrad@...>:

> I've used pregreet on some very high volume MX for months, and had one FP.

I had these two (within one year), both with sendmails with (presumably!)
the same (?) milter.

--
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.hildebrandt@... | http://www.charite.de

Claus Assmann:
> On Thu, Sep 30, 2010, Victor Duchovni wrote:
>
> > Do you have a tcpdump capture? From the above it sounds like HELO is
> > sent before the 220 banner. That's a protocol error.
>
> Is it?
>
> 4.3.1 Sequencing Overview
> ...
>    One important reply is the connection greeting.  Normally, a receiver
>    will send a 220 "Service ready" reply when the connection is
>    completed.  The sender SHOULD wait for this greeting message before
>    sending any commands.
>
> So this is "just" a SHOULD, not a MUST, hence not a protocol error
> per se. Any real MTA will obey the SHOULD requirement of course.

Also, multi-line 220 greetings are not documented up to RFC 2821,
but they have been in use for more than 15 years; and "hangup after
521" is still not officially blessed, but postscreen will send it
to get rid of clients immediately (smtpd has supported this as of
Postfix 2.6).

These features don't appear to hamper inter-operability with
well-behaved MTAs (and the more sites deploy these features,
the less likely legitimate mail is to break).

	 Wietse

---------- Original Message ----------------------------------
From: Claus Assmann <ca+postfix-users@...>
Date:  Thu, 30 Sep 2010 11:07:23 -0700

>On Thu, Sep 30, 2010, Victor Duchovni wrote:
>
>> Do you have a tcpdump capture? From the above it sounds like HELO is
>> sent before the 220 banner. That's a protocol error.
>
>Is it?
>
>4.3.1 Sequencing Overview
>...
>   One important reply is the connection greeting.  Normally, a receiver
>   will send a 220 "Service ready" reply when the connection is
>   completed.  The sender SHOULD wait for this greeting message before
>   sending any commands.
>
>So this is "just" a SHOULD, not a MUST, hence not a protocol error
>per se. Any real MTA will obey the SHOULD requirement of course.

I've used pregreet on some very high volume MX for months, and had one FP.

As I glance through the list of pregreeters

egrep -i "pregreet" /var/log/maillog | awk '{print $NF}' | sort -f | uniq -ic |
sort -rnf | less

complete crap

22944 localhost??
2353 USER??
1664 samlab??
1601 adsl-dynamic-pool-xxx.fpt.vn??
1529 HOME??
1519 dynamic.vdc.vn??
1476 SERVER??
1287 adsl-dynamic-pool-xxx.hcm.fpt.vn??
1280 PC??
1268 COMPUTER??
1232 66.45.16.66??
1226 wimax-client.yota.ru??
1203 COMP??
1202 ADMIN??
1188 adsl.viettel.vn??
1083 ??
  940 static.vdc.vn??
  862 UserPC??
  840 philka??
  788 Loner-XP??
  749 advertise-bz.cn??
  703 QUIT??
  689 ????????
  577 pc2009??
  558 DESKTOP??
  513 ABC??
  509 vista??
  501 system.mail??
  498 mailin-02.mx.aol.com??
  466 mycomp??
  462 homecomputer??
  461 mycom??
  430 customer-189-217-67-24.cablevision.net.mx??
  429 win7xp??
  413 ABTS-North-Dynamic-061.206.173.122.airtelbroadband.in??
  396 Paradise??
  383 ge-3-3-0-core-as12455.orange.co.ke??
  375 ???????
  360 wtl.worldcall.net.pk??
  359 hw-media.com??
  347 techtargetlists.com??
  343 ??????
  333 yahoo.com??
  322 PC1??
  310 crnnetwork.com??
  303 INDIA??
  302 PC2??
  299 bldr-media.com??
  296 95-52-182-246.dynamic.komi.dslavangard.ru??
  290 SYSTEM??
  290 COMP1??
  281 adsl.hnpt.com.vn??
  281 SLT-BB-CUST.slt.lk??
  280 windowsxpsp3??
  280 ACER??
  266 static.vnpt-hanoi.com.vn??
  260 LENOVO??
  254 USER-PC??
  251 pal??
  247 host222-252-static.39-79-b.business.telecomitalia.it??
  244 saleemi-71221d1??
  244 OFFICE??
  233 201-89-23-194.pgosm301.ipd.brasiltelecom.net.br??
  232 178-162-190-11.local??
  231 Intel??
  230 ipaddr.enet.vn??
  229 microsof-265881??
  227 computer_1??
  220 x-team??
  219 inside-ip-115.astranet.ru??
  218 hn.kd.ny.adsl??
  215 XP??
  213 MAY_INKD??
  212 changeme1??
  212 COMPAQ??
  210 ITFRIEND??
  209 sicowin??
  207 news.cygnusb2bmail.com??
  207 everest??
  206 codename??
  203 COMPUTER1??
  196 ?????????
  187 newtopcommercialcollectors.info??
  186 MTComputer??
  183 wolf??
  183 MAYCHU??
  183 COM??
  182 SERVIDOR??
  182 PC3??
  181 blackedition??
  178 PC4??
  174 static.turktelekom.com.tr??
  174 microsof-e753d7??
  174 mail.cnyy.net??
  170 d-2657b85a02674??
  169 WorldnetLL-43-58.pacenet-india.com??
  166 FFK-PC??
  165 200-206-144-65.dsl.telesp.net.br??
  164 195.3.145.72??
  161 EQUIPO01??
  159 DELL??
  157 xpwindows7??
  156 PC05??
  156 INTRACLUB.COM??
  155 ITQUANGNAM??
  154 lonerxp??
  151 h95-110-7-11.dyn.bashtel.ru??
  151 WINXP??
  149 g-3-3-0-core-as12455.telkom.co.ke??
  149 Colossus??
  149 ?????
  148 162-34-132-95.pool.ukrtel.net??
  147 COMP2??
  146 HP??
  144 usercomp??
  144 ali-2ae3fc4aa2a??
  142 truefaster??
  142 kongzhi.net??
  142 administrator??
  141 COMP3??
  140 darkedition??
  139 den-media.com??
  138 elecp-media.com??
  138 LAPTOP??
  137 microsof-6886c2??
  136 PC01??
  135 SUPER??
  135 61-66-133-95.pool.ukrtel.net??
  133 henk??
  133 Komp??
  133 BOSS??
  132 sh-51d3bb518c1f??
  131 undef-salt-kh.maxnet.ua??
  131 computer-6f8e82??
  130 A??
  127 khanhbinh??
  126 6a49e22334874f4??
  125 sai??
  125 COM3??
  124 peice-training.com??
  124 filial003-07??
  124 MAY??
  123 PC5??
  122 Secsys01??
  121 SHREE??
  120 MAY02??
  120 MAY01??
  120 ?????-????
  118 WELCOME??
  118 SYSTEM1??
  117 sys??
  117 pentium??
  115 grebenukov.ett.ua??
  115 MAY2??
  115 MAY2??
  114 topk??
  114 klb??
  114 H
  113 HCL??
  113 COM2??
  113 ASD??
  112 wwi-media.com??
  112 microsof-37f618??
  112 TOSHIBA??
  112 ??????????
  111 besttopworkathome.info??
  111 Denis??
  110 game-rig??
  107 abu_mada_xpsp3_??
  107 50.subnet125-163-55.speedy.telkom.net.id??
  106 diablo??
  106 ASA??
  105 dialog_pc??
  105 PERSONAL??
  105 PC04??
  105 Home-PC??
  104 myeliteb2bcollectors.info??
  104 MARINA??
  103 microsof-be41ff??
  103 USER1??
  103 NOTEBOOK??
  103 85.subnet125-163-96.speedy.telkom.net.id??
  102 pro??
  102 net??
  102 marketing.cygnusb2bmail.com??
  102 Main??
  100 speed_xp??
  100 LASTXP??
  100 DIRECTOR??
  100 COM1??

... etc for 100K more lines

must wait for SMTP Greeting is enough of a best practice for me.

screw "should" wait

Len

* Ralf Hildebrandt <Ralf.Hildebrandt@...>:

> 192.109.31.12 is running:
> 220 mail.EMBL-Hamburg.DE ESMTP Sendmail 8.13.8/8.13.8/Debian-2; Thu, 30 Sep
2010 16:06:22 +0200; (No UCE/UBE) logging access from:
mail.charite.de(OK)-mail.charite.de [141.42.202.200]

I found another one:
220 klx11.klinikum-amberg.de ESMTP mailserver; Thu, 30 Sep 2010 20:55:45 +0200;
(No UCE/UBE) logging access from: mail.charite.de(OK)-mail.charite.de
[141.42.202.200]

That banner looks suspiciously similar!

What is this "(No UCE/UBE) logging access from: " bit in the banner?
Is that the default? Could find it in the sendmail sourcecode.

# zfgrep -h "550 5.5.1 Protocol error; from=<>, to=" /var/log/OLD/*/mail.log* |
awk '{print $10}' | sort | uniq -c|sort -n
       1 [169.230.27.17]:
       1 [192.109.31.12]:
       1 [192.109.31.26]:
       1 [194.85.224.36]:
       1 [209.253.146.109]:
       1 [38.115.159.132]:
       1 [65.39.224.170]:
       1 [80.146.166.242]:
       2 [194.63.247.43]:
       2 [195.134.100.81]:
       2 [217.25.178.38]:
       3 [195.134.100.69]:
       3 [217.25.178.9]:
       5 [62.245.197.11]:

--
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.hildebrandt@... | http://www.charite.de

On Thu, Sep 30, 2010 at 09:27:30PM +0200, Ralf Hildebrandt wrote:

> * Ralf Hildebrandt <Ralf.Hildebrandt@...>:
>
> > 192.109.31.12 is running:
> > 220 mail.EMBL-Hamburg.DE ESMTP Sendmail 8.13.8/8.13.8/Debian-2; Thu, 30 Sep
2010 16:06:22 +0200; (No UCE/UBE) logging access from:
mail.charite.de(OK)-mail.charite.de [141.42.202.200]
>
> I found another one:
> 220 klx11.klinikum-amberg.de ESMTP mailserver; Thu, 30 Sep 2010 20:55:45
+0200; (No UCE/UBE) logging access from: mail.charite.de(OK)-mail.charite.de
[141.42.202.200]
>
> That banner looks suspiciously similar!
>
> What is this "(No UCE/UBE) logging access from: " bit in the banner?
> Is that the default? Could find it in the sendmail sourcecode.

The Sendmail banner line is configurable in "sendmail.cf".

--
	 Viktor.

Hi there,

I am using Postfix 2.3.3 to integrate with RedHat Open LDAP server. I
verified that my LDAP set up is correct, because I used the same
configuration on another Postfix server, it worked.
The following is how I ask LDAP to validate domain name.

main.cf:

mydestination = $myhostname, localhost.$mydomain, localhost,
ldap:acceptdomains

acceptdomains_server_host = ldap://<hostname>:389/
acceptdomains_server_port = 389
acceptdomains_search_base =
ou=domain,dc=hubdirect,dc=int,dc=medplus,dc=com
acceptdomains_query_filter = (domainname=%s)
acceptdomains_result_attribute = domainname

When I do postmap for testing a domain: test.medplus.com, here is what I
get.

postmap -qv  test.medplus.com ldap:acceptdomains
postmap: fatal: open database  test.medplus.com.db: No such file or
directory

postmap -q  test.medplus.com ldap:acceptdomains
  <---return nothing in command line--->

When I looked in LDAP log, I see the query issued correctly but nothing
is retrieved.

However, in another environment having identical setup, I am getting
"test.medplus.com" back in response, thus showing Postfix knows this
domain.

Any idea why Postfix lookup LDAP does not work in this particular
instance?  The only difference between the two environment is that:
- on the one working, my LDAP root node has the
"dc=int,dc=medplus,dc=com".
- on the one not working, my LDAP root node has "dc=medplus,dc=com", and
"dc=int" is one level below the root.

Both entries have the same DN path "dc=int,dc=medplus,dc=com".


Thanks,

Yan










Confidentiality Notice: The information contained in this electronic
transmission is confidential and may be legally privileged. It is intended only
for the addressee(s) named above. If you are not an intended recipient, be aware
that any disclosure, copying, distribution or use of the information contained
in this transmission is prohibited and may be unlawful. If you have received
this transmission in error, please notify us by telephone (513) 229-5500 or by
email (postmaster@...). After replying, please erase it from your
computer system.

On 09/30/2010 09:54 PM, Zhou, Yan wrote:
> Hi there,
>
> I am using Postfix 2.3.3 to integrate with RedHat Open LDAP server. I
> verified that my LDAP set up is correct, because I used the same
> configuration on another Postfix server, it worked.
> The following is how I ask LDAP to validate domain name.
>
> main.cf:
>
> mydestination = $myhostname, localhost.$mydomain, localhost,
> ldap:acceptdomains
>
> acceptdomains_server_host = ldap://<hostname>:389/
> acceptdomains_server_port = 389
> acceptdomains_search_base =
> ou=domain,dc=hubdirect,dc=int,dc=medplus,dc=com
> acceptdomains_query_filter = (domainname=%s)
> acceptdomains_result_attribute = domainname
>
> When I do postmap for testing a domain: test.medplus.com, here is what I
> get.
>
> postmap -qv  test.medplus.com ldap:acceptdomains
> postmap: fatal: open database  test.medplus.com.db: No such file or
> directory
>

You're asking "test.medplus.com" for key "v".
man postmap for correct syntax.

> postmap -q  test.medplus.com ldap:acceptdomains
>   <---return nothing in command line--->
>
> When I looked in LDAP log, I see the query issued correctly but nothing
> is retrieved.
>

Where is that log ? What does the LDAP *server* log ?

Map files must be fully named; "acceptdomains" is not a full pathname.


--
J.

Le 30/09/2010 12:48, Christian Rößner a écrit :
> Hi,
>
> I have a problem that the smtpd_proxy_filter option has higher priority than a
FILTER setting in an access table:
>


if you use a proxy filter, _all_ mail goes to the proxy filter.

> Sep 30 12:33:04 mx0 postfix/smtpd[5250]: warning: access table
cidr:/etc/postfix/maps/client_access.cidr: with smtpd_proxy_filter specified,
action FILTER is unavailable
>
> What I need is a mechanism to re-route a mail to a different policy-bank in
amavis, if a MTA-client is found in a whitelist:

either
- forget about proxy filter and use after-the-queue filtering (with
content_filter, FILTER and/or transports)
- or implement the dispatching in your proxy filter.
- if your WL is IP based, put that in your firewall/NAT/routing config.

> smtp       inet  n       -       -       -       1       postscreen
> smtpd      pass  -       -       -       -       10      smtpd
>      -o smtp_bind_address=127.0.0.1
>      -o smtpd_proxy_filter=[127.0.0.1]:10024
>      -o smtpd_client_connection_rate_limit=5
>      -o smtpd_client_message_rate_limit=5
>      -o smtpd_client_recipient_rate_limit=30
> dnsblog   unix  -        -      -       -       0       dnsblog
> ...
>
>
> In main.cf:
>
> smtpd_recipient_restrictions =
>      ...
>      check_client_access cidr:/etc/postfix/maps/client_access.cidr,
>      ...
>
>
> /etc/postfix/maps/client_access.cidr:
> # Whitelisting
> 193.239.107.22  FILTER lmtp-amavis:[::1]:10027
>
>
> amavis:
>
> $interface_policy{'10027'} = 'WHITELIST';
> $policy_bank{'WHITELIST'} = {
>    allow_disclaimers               =>  1,
>    bypass_spam_checks_maps         =>  [1],                                  #
I want to disable spam-checks for SWL and DWL
>    terminate_dsn_on_notify_success =>  0,
> };
>
>
> This test here is a pre-prototype for thinking about coding a policy-service
that respects swl.spamhaus.org and dwl.spamhaus.org. Yet I do not know how to
_really_ whitelist candidates on these lists. So I took my friend Uwe's MTA for
a first test of whitelisting.
>
> Also the question for postscreen: Does it allow negative scoring of dnsbl? So
I could use that lookup mechanism, too. At the moment I try to negative score
whitelists in policyd-weight.
>
> This all is not so easy for me right now :-)
>
> Best regards
> Christian
>
>
> ---
> Roessner-Network-Solutions
> Bachelor of Science Informatik
> Nahrungsberg 81, 35390 Gießen
> F: +49 641 5879091, M: +49 176 93118939
> USt-IdNr.: DE225643613
> http://www.roessner-network-solutions.com
>

Here is a similar incident with a milter not understanding multiline
responses, as well as shooting out the query without waiting for a
greeting. Below is my side of the correspondence with its author
and with the postmaster of the site where it was first observed.


From: Mark Martinec <Mark.Martinec@...>
To: Eugene Kurmanin <...>
Subject: smf-sav shoots HELO without waiting for full greeting,
   violating SMTP protocol
Date: Tue, 27 Oct 2009 15:41:40 +0100

I know the smf-sav hasn't been maintained for a while now, but my guess
is that some sites are still using it. I wonder if you are aware of the
SMTP protocol violation caused by smf-sav, which can cause the receiving
MTA to drop the connection right away, so subsequently the SAV fails
on the sending site.

The key problem here is that a SMTP protocol allows continuation of
responses (a '-' instead of a ' ' after the status code), while the
smf-sav fails to read all response lines first, but goes straight to
sending a HELO command. A more picky MTAs will disconnect the session
at that point.

Below is my message to postmasters of "Max Planck Institute for chemical
physics of solids", which possibly is using your software, according to
tcpdump.

Please consider fixing the issue in the next release.

( my message to mpg.de : )

While investigating mail delivery problems for messages sent from our
institute (e.g. from xxx@...) to xxx.mpg.de, I discovered
that the reason for rejections like:

   550 5.7.1 <xxx@...>...
      Sender address verification failed

is that your sender address verification implementation violates the
SMTP protocol by shooting out a command:

   HELO mailgate.xxx.mpg.de

without first waiting for the reception of the complete greeting message.

I have now listed the xxx.xxx.xxx.xxx and xxx.xxx.xxx.xxx as broken mailers,
so as to ignore the violation in the future, but it would be nice
to fix your SAV, as it may give you trouble with other mail as well.

I wonder what software are you using for the SAV component.
Could it be that you are using an old smf-sav milter, which is
known to suffer from this defect?

[...]

Eugene writes:
> Sure, you are right. This bug was fixed in commercial software
> more than 2 years ago.
> This is a fixed code (replaced code of buggy function):

Hmmm. I don't think this will work reliably.

I see two problems there. One is that it assumes the SMTP response lines
will start at a TCP segment boundaries - which happens to be true in
most cases, but may not be, perhaps due to anti-spam firewalls stalling
the SMTP response and feeding it back by a slow trickle in several
packets, or perhaps due to packet fragmentation. The SMTP response code
can only start at a line boundary (first line, or following a CRLF).

The other problem, which affects us here directly is that the while loop
exits as soon as it encounters a LF at the end of a TCP segment.
It should continue reading the response continuation lines for as long
as the continuation character indicates 'more' (i.e. '2xx-...').

Let me illustrate what happens in case of a Postfix MTA with postscreen
enabled. It sends it greeting in two lines, the first line indicates
(with a '-') that continuation follows. There is also a few seconds
pause between the first and the second response line:

220-mail.ijs.si ESMTP Postfix
220 mail.ijs.si ESMTP Postfix

Only after a line with no 'more' mark is received, is the client
allowed to speak.

So I don't see a shortcut way out here, the client code needs
to recognize the concept of 'lines', and it must understand the
concept of multiline SMTP responses to be truly SMTP-compliant.
I've seen other mailers responding with multi-line greetings too.

I think some OpenBSD anti-spam sw is even more challenging to the client,
breaking the initial response into multiple TCP segments, with pauses
inbetween. The idea is to allow SMTP-compliant clients to send mail,
while stopping some quick-and-dirty malware mail-sending software
which tries to cut corners.

Regards
    Mark


> But it works, as far as I know :)
> It was tested with OpenBSD spamd anti-spam daemon smth like that
> techniques.

Here is a SMTP SAV session as captured by a tcpdump between my [...] computer
running sendmail + smf-sav with your patch applied, and our institute's
main mailer (as a SAV response to my message sent from office to home):

220-mail.ijs.si ESMTP Postfix
HELO xxx.ijs.si
521 5.5.1 Protocol error
RSET

As you can see, the smf-sav does not wait for the complete greeting
message, it only waits until the end of the first line. The greeting
is a multiline response with a short pause between the
first line and its continuation line:

220-mail.ijs.si ESMTP Postfix
(pause)
220 mail.ijs.si ESMTP Postfix

and the client must not send a SMTP command until it receives
the complete SMTP response (as dictated by RFC 2821).

The session should have looked like:

220-mail.ijs.si ESMTP Postfix
220 mail.ijs.si ESMTP Postfix
HELO xxx.ijs.si
250 mail.ijs.si

[...]
Btw, I checked another SAV-capable milter (spamilter by Neal Horman),
and it does not suffer from this defect, it understands multiline
SMTP responses properly.

As postscreen is a relatively new feature of Postfix, you may not
encounter it often yet, but as time passes, more sites will be turning
it on.

   Mark

After a relay serving as a backup MX enqueues a message because the
primary is down, and then the relay is reloaded with a different
configuration such that it no longer is relaying mail, will Postfix
still continue to attempt forwarding the already-queued messages?
--
Yang Zhang
http://yz.mit.edu/

Thanks, Jeroen, see my comment below.

> > postmap -qv  test.medplus.com ldap:acceptdomains
> > postmap: fatal: open database  test.medplus.com.db: No such file or
> > directory
> >
>

This is the output of postmap -vq  test.medplus.com  ldap:acceptdomains

It does query into LDAP but returns nothing when the same LDAP query
returns value in another LDAP browser.

postmap: dict_open: ldap:acceptdomains
postmap: dict_ldap_lookup: In dict_ldap_lookup
postmap: dict_ldap_lookup: No existing connection for LDAP source
acceptdomains, reopening
postmap: dict_ldap_connect: Connecting to server
ldap://hub-dev-app01.dev.medplus.com:389/
postmap: dict_ldap_connect: Actual Protocol version used is 2.
postmap: dict_ldap_connect: Binding to server
ldap://hub-dev-app01.dev.medplus.com:389/ as dn
postmap: dict_ldap_connect: Successful bind to server
ldap://hub-dev-app01.dev.medplus.com:389/ as
postmap: dict_ldap_connect: Cached connection handle for LDAP source
acceptdomains
postmap: dict_ldap_lookup: acceptdomains: Searching with filter
(domainname=test.medplus.com)
postmap: dict_ldap_get_values[1]: Search found 0 match(es)
postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
postmap: dict_ldap_lookup: Search returned nothing
postmap: dict_ldap_close: Closed connection handle for LDAP source
acceptdomains


> > postmap -q  test.medplus.com ldap:acceptdomains
> >   <---return nothing in command line--->
> >
> > When I looked in LDAP log, I see the query issued correctly but
> nothing
> > is retrieved.
> >
>
> Where is that log ? What does the LDAP *server* log ?
>

I am referring to Open LDAP Server access log, I see the query being
issued, the same query from LDAP browser does return value, but the one
from Postfix returns nothing.


> Map files must be fully named; "acceptdomains" is not a full pathname.
>
>
> --
> J.

I think what I have is an alternative option, unless it is no longer
supported by Postfix 2.3.3?  That works with same version of Postfix in
another environment. I also see output from postmap -vq.

Yan













Confidentiality Notice: The information contained in this electronic
transmission is confidential and may be legally privileged. It is intended only
for the addressee(s) named above. If you are not an intended recipient, be aware
that any disclosure, copying, distribution or use of the information contained
in this transmission is prohibited and may be unlawful. If you have received
this transmission in error, please notify us by telephone (513) 229-5500 or by
email (postmaster@...). After replying, please erase it from your
computer system.

On Thu, Sep 30, 2010 at 03:55:50PM -0700, Yang Zhang wrote:

> After a relay serving as a backup MX enqueues a message because the
> primary is down, and then the relay is reloaded with a different
> configuration such that it no longer is relaying mail, will Postfix
> still continue to attempt forwarding the already-queued messages?

Yes, of course. Mail comes in, and then it goes out. The two activities
are largely decoupled.

--
	 Viktor.