Re: Preventing domain mails from outside

[Paweł Leśniak]

Specifically I added 

check_sender_access hash:/etc/postfix/copycats 
to 
smtpd_recipient_restrictions=

after the mynetworks and SASL authenticated permits, added
an /etc/postfix/copycats file containing

thisisreallymydomain.com REJECT

  
This seems to be effective at stopping some of the spam, but other still

arrives, with headers like:

  

Received: by www.thisisireallymydomain.com (Postfix)
 id 3C916254775; Tue, 30 Dec 2008 03:50:01 -0800 (PST)
Delivered-To: n...@thisisireallymydomain.com
Received: from alkhorayef.com (unknown [91.189.132.54])
 by www.thisisireallymydomain.com (Postfix) with SMTP id B31A025472A
 for ; Tue, 30 Dec 2008 03:49:59 -0800


(PST)
  

To: 
Subject: Celebrate a victory in love
From: 
MIME-Version: 1.0
Importance: High
Content-Type: text/html
Message-Id: <20081230114959.b31a0254...@www.thisisireallymydomain.com>
Date: Tue, 30 Dec 2008 03:49:59 -0800 (PST)
Return-Path: p...@acculab.com
X-OriginalArrivalTime: 30 Dec 2008 11:50:31.0292 (UTC)


FILETIME=[D10EABC0:01C96A74]

This arrives in the inbox of no...@thisisreallymydomain.com with no
indication of the
actual source being a different domain, as "From"
n...@thisisreallymydomain.com.
  


How come your server receives mail for thisisireallymydomain.com ?

Received: from alkhorayef.com (unknown [91.189.132.54])
by www.thisisireallymydomain.com (Postfix) with SMTP id B31A025472A
for ; Tue, 30 Dec 2008 03:49:59 -0800
Delivered-To: n...@thisisireallymydomain.com

If this is ok, than you have to add also this domain to 
check_sender_access table.
Are you using reject_unauth_destination ? This one should be before 
check_sender_access.



Pawel

Re: Backscatter with forged return-path

[Paweł Leśniak]

Jim Wright pisze:

On Jan 26, 2009, at 7:41 AM, Paweł Leśniak wrote:

One of our users is getting lots of returned mails because his email 
address is used as return-path by spammer(s).


I would guess that your system accepting mail from unknown servers?  
Start blocking those, and you'll find that these bounces will drop 
significantly.  Hard to tell from your sanitized error report...


Well, I have no idea what is missing in my previous post. Could you 
please tell me what's missing?


Here's excerpt from logs:
Jan 26 13:05:41 mail postfix/smtpd[2432]: connect from 
static-ip-114-118-134-202.rev.dyxnet.com[202.134.118.114]
Jan 26 13:05:42 mail postgrey[1086]: action=pass, reason=triplet found, 
delay=727, client_name=static-ip-114-118-134-202.rev.dyxnet.com, 
client_address=202.134.118.114, recipient=u...@example.com
Jan 26 13:05:42 mail postfix/policy-spf[2500]: handler 
sender_policy_framework: is decisive.
Jan 26 13:05:42 mail postfix/policy-spf[2500]: : Policy action=PREPEND 
Received-SPF: none (server.hipwah.com: No applicable sender policy 
available) receiver=mail.example.com; identity=helo; 
helo=SERVER.hipwah.com; client-ip=202.134.118.114
Jan 26 13:05:42 mail postgrey[1086]: action=pass, reason=triplet found, 
client_name=static-ip-114-118-134-202.rev.dyxnet.com, 
client_address=202.134.118.114, recipient=u...@example.com
Jan 26 13:05:42 mail postfix/smtpd[2432]: B02B3C4E69: 
client=static-ip-114-118-134-202.rev.dyxnet.com[202.134.118.114]
Jan 26 13:05:43 mail postfix/cleanup[1895]: B02B3C4E69: 
message-id=
Jan 26 13:05:43 mail postfix/qmgr[29447]: B02B3C4E69: from=<>, 
size=3464, nrcpt=1 (queue active)
Jan 26 13:05:43 mail amavis[28992]: (28992-06) ESMTP::10024 
/var/amavis/tmp/amavis-20090126T122953-28992: <> ->  
SIZE=3464 Received: from mail.example.com ([127.0.0.1]) by localhost 
(mail.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP for 
; Mon, 26 Jan 2009 13:05:43 +0100 (CET)
Jan 26 13:05:43 mail amavis[28992]: (28992-06) Checking: RddKfnGyz5HQ 
[202.134.118.114] <> -> 
Jan 26 13:05:43 mail amavis[28992]: (28992-06) p004 1 Content-Type: 
multipart/report
Jan 26 13:05:43 mail amavis[28992]: (28992-06) p001 1/1 Content-Type: 
text/plain, size: 286 B, name:
Jan 26 13:05:43 mail amavis[28992]: (28992-06) p002 1/2 Content-Type: 
message/delivery-status, size: 607 B, name:
Jan 26 13:05:43 mail amavis[28992]: (28992-06) p005 1/3 Content-Type: 
message/rfc822
Jan 26 13:05:43 mail amavis[28992]: (28992-06) p003 1/3/1 Content-Type: 
text/plain, size: 459 B, name:
Jan 26 13:05:43 mail postfix/smtpd[2432]: disconnect from 
static-ip-114-118-134-202.rev.dyxnet.com[202.134.118.114]
Jan 26 13:05:44 mail amavis[28992]: (28992-06) SPAM-TAG, <> -> 
, Yes, score=6.86 tagged_above=-999 required=5 
tests=[URIBL_AB_SURBL=1.86, URIBL_BLACK=5]

Jan 26 13:05:44 mail postfix/smtpd[1899]: connect from unknown[127.0.0.1]
Jan 26 13:05:44 mail postfix/smtpd[1899]: 588D6C5070: 
client=unknown[127.0.0.1]
Jan 26 13:05:44 mail postfix/cleanup[1895]: 588D6C5070: 
message-id=
Jan 26 13:05:44 mail postfix/qmgr[29447]: 588D6C5070: from=<>, 
size=4129, nrcpt=1 (queue active)

Jan 26 13:05:44 mail postfix/smtpd[1899]: disconnect from unknown[127.0.0.1]
Jan 26 13:05:44 mail amavis[28992]: (28992-06) FWD via SMTP: <> -> 
,BODY=7BIT 250 2.6.0 Ok, id=28992-06, from 
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 588D6C5070
Jan 26 13:05:44 mail amavis[28992]: (28992-06) Passed SPAMMY, 
[202.134.118.114] [202.134.118.114] <> -> , 
Message-ID: , mail_id: 
RddKfnGyz5HQ, Hits: 6.86, size: 3462, queued_as: 588D6C5070, 913 ms
Jan 26 13:05:44 mail postfix/smtp[1896]: B02B3C4E69: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.3, 
delays=1.4/0/0/0.92, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
588D6C5070)

Jan 26 13:05:44 mail postfix/qmgr[29447]: B02B3C4E69: removed
Jan 26 13:05:44 mail amavis[28992]: (28992-06) TIMING [total 921 ms] - 
SMTP greeting: 3 (0%)0, SMTP EHLO: 1 (0%)0, SMTP pre-MAIL: 1 (0%)0, SMTP 
pre-DATA-flush: 3 (0%)1, SMTP DATA: 36 (4%)5, check_init: 1 (0%)5, 
digest_hdr: 1 (0%)5, digest_body: 0 (0%)5, gen_mail_id: 1 (0%)5, 
mime_decode: 24 (3%)8, get-file-type3: 26 (3%)11, decompose_part: 1 
(0%)11, decompose_part: 1 (0%)11, decompose_part: 1 (0%)11, 
parts_decode: 0 (0%)11, check_header: 2 (0%)11, AV-scan-1: 6 (1%)12, 
spam-wb-list: 2 (0%)12, SA parse: 4 (0%)12, SA check: 752 (82%)94, 
update_cache: 8 (1%)95, decide_mail_destiny: 1 (0%)95, fwd-connect: 8 
(1%)96, fwd-mail-pip: 2 (0%)96, fwd-rcpt-pip: 0 (0%)96, fwd-data-chkpnt: 
0 (0%)96, write-header: 1 (0%)96, fwd-data-contents: 0 (0%)96, 
fwd-end-chkpnt: 18 (2%)98, prepare-dsn: 1 (0%)98, main_log_entry: 11 
(1%)99, update_snmp: 2 (0%)100, SMTP pre-response: 1 (0%)100, SMTP 
response: 0 (0%)100, unlink-3-files: 1 (0%)100, rundown: 1 (0%)100
Jan 26 13:05:44 mail postfix/local[1900]: 588D6C5070: 
to=, orig_to=, relay=local, 
delay=0.05, delays=0.01/0/0/0.03, dsn=2.0.0, statu

Re: Backscatter with forged return-path

[Paweł Leśniak]

Chris Babcock pisze:

On Mon, 26 Jan 2009 08:52:00 -0600
Jim Wright  wrote:

  

On Jan 26, 2009, at 7:41 AM, Paweł Leśniak wrote:



One of our users is getting lots of returned mails because his
email address is used as return-path by spammer(s).
  
I would guess that your system accepting mail from unknown servers?   
Start blocking those, and you'll find that these bounces will drop  
significantly.  Hard to tell from your sanitized error report...



I think the OP already ruled that out. 
  
I'm not sure what I should've ruled out... could you please be more 
specific which statement above do you mean?

The question is whether there is a milter that tracks the message IDs
of outbound mail so that they can be used to check bounce notices for
authenticity. That seems to be rather resource intensive, even if the
regular logs were used... and I don't believe that intermediate hops
are obligated to keep all of those headers in transit.
  
I'm not using any BATV solution right now (and I can't find strongly 
positive opinions on it in this mailing list's archives). Inside the 
message in my original posting there is Message-ID inside of the 
enveloped body. So in this particular case it'd be (I think) as simple 
as check body for specific Message-ID. But I'm not sure if this check 
won't be the cause of other troubles.

SPF and DKIM are designed to deal with the joe job issue, but even with
strict sending policies I don't know the chances that the recieving
machine will implement either of these policies in a way that deals
constructively with backscatter. 
  
AFAIK SPF and DKIM to help ME would have to be used by mailserver from 
which I'm receiving backscatter. And finally it's backscatter, so if 
bouncing mailserver does not take advantage of SPF record of my domain, 
it has no possibility to know whether to bounce the message or not (of 
course as I stated before IP of original sender (who fakes return-path) 
is on spamhaus' zen RBL, so it could be rejected by bouncing server).
So again it comes to my mind that I'm getting backscatter because of 
wrong configuration on the other side.


Thank you for replies.

Regards
Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

mouss pisze:

This doesn't mean all your users mail has such message-id's:
- the message-id is added by the MUA. so if the MUA is named
joe.my.computer, the message-id will use this instead of example.com.

- if your users post from other servers (their ISP, hotel, ...), the
message-id may be that of the ISP/hotel/.. assuming their MUA doesn't
generate a message-id.
  
Unfortunately I was optimist and checked what's doing my MUA. Of course 
some of users use
different MUAs, and they create Message-ID of other forms (with short 
name after "@").

I believe my question has to be rewritten though.

you can't combine envelope sender and a body_check rule.
For that, you would need a proxy_filter to pass mail to different
smtpd's (each with its own cleanup, and thus header/body checks) based
on the sender.
  
What is the best solution then (assuming I was so wrong about 
message-ids of my mails)? Do I have to use some BATV proxy to sign every 
outgoing mail with some cookie?


Thanks for answer

Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

Jim Wright pisze:
Jan 26 13:05:42 mail postfix/policy-spf[2500]: : Policy 
action=PREPEND Received-SPF: none (server.hipwah.com: No applicable 
sender policy available) receiver=mail.example.com; identity=helo; 
helo=SERVER.hipwah.com; client-ip=202.134.118.114

reject_unknown_hostname

SERVER.hipwah.com has no DNS A or MX record.


[r...@mail postfix]# host server.hipwah.com
Host server.hipwah.com not found: 3(NXDOMAIN)
[r...@mail postfix]# host -t mx server.hipwah.com
Host server.hipwah.com not found: 3(NXDOMAIN)
[r...@mail postfix]# host -t mx hipwah.com
hipwah.com mail is handled by 5 mail.hipwah.com.
[r...@mail postfix]# host mail.hipwah.com
mail.hipwah.com has address 202.134.118.114


I may be wrong, but I think I should not block sender on helo basis?
Jan 26 13:05:41 mail postfix/smtpd[2432]: connect from 
static-ip-114-118-134-202.rev.dyxnet.com[202.134.118.114]
Jan 26 13:05:42 mail postgrey[1086]: action=pass, reason=triplet found, 
delay=727, client_name=static-ip-114-118-134-202.rev.dyxnet.com, 
client_address=202.134.118.114, recipient=u...@example.com


From my point of view it looks like reject_unknown_helo_hostname is far 
to agressive, while reject_unknown_client_hostname and 
reject_unknown_reverse_client_hostname would both permit this mail. 
Correct me please if I'm wrong.



Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

mouss pisze:

if all outbound mail goes via your server, you can use "poorman BATV".
for example: use smtp_generic to rewrite j...@example.com to say
joe+bou...@example.com, where '+' is your extension delimiter.

then you can reject mail from the null sender if it is not sent to a
/\+bou...@example\.com$/ address.

but if your users can send via other servers (ISP, hotel, ...), then you
can't use this to block like this. but you can use it as whitelist
mechanism, and implement aggressive checks if the recipient doesn't
match the +bounce extension (I'm talking about null sender case of course).
  
So far so good. Users of our mailserver are allowed to send only via our 
mailserver (which hosts

webmail service for use wherever SMTP port is firewalled).

Another problem here is that some mailing-list managers use the envelope
sender to validate subscription.

Note that the +bounce address is replay-able. I'm not sure this is an
issue. if so, a cron job could update the extension on
daily/weekly/monthly basis...
  
I'm not sure if I fully understand. If I would not change "+ext" 
extention in time, this wouldn't be a problem
for mailing lists? But then some users are using address books and 
eventually they would remember
email address with extension. If those statements are true, then this 
solution is quite bad for me.


Thank you for clarifying my mistakes

Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

Jim Wright pisze:

On Jan 26, 2009, at 4:05 PM, Paweł Leśniak wrote:


I may be wrong, but I think I should not block sender on helo basis?


Most of what will be blocked are zombie systems that send no 
legitimate mail, a very small number of legitimate mails 'may' be 
blocked.  It's a personal preference, I bounce these with 
unknown_hostname_reject_code = 450 in case it's a transient error on 
their end.

OK
As you've suggested I've changed smtpd_recipient_restrictions to include 
reject_unknown_*_hostname, so now I have:

smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/spam_lovers.map,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_unauth_destination,
reject_unlisted_sender,
check_sender_access hash:/etc/postfix/restricted_senders.map,
reject_sender_login_mismatch,
check_client_access pcre:/etc/postfix/check_client_fqdn.pcre,
check_client_access cidr:/etc/postfix/postfix-dnswl-permit,
check_recipient_access hash:/etc/postfix/restricted_recipients.map,
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
reject_unknown_helo_hostname,
reject_rbl_client zen.spamhaus.org,
check_policy_service unix:private/policy,
check_greylist,
reject_unauth_pipelining
permit

Default action of  reject_unknown_*_hostname is 450, so sender's mailer 
should try to deliver message again after some time. As far as I can see 
now in my logs, nothing like this happens.
Mostly mails rejected (for future delivery) are being sent in bulks of 4 
emails at once to different email addresses. This almost definitely 
solves my problem for now. No more forged returned mails right now 
(after 13 hours of tests). And if something bad happens (when some mail 
get rejected for future delivery) I hope I'll be able to find it.


Thank you for help

Regards

Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

mouss pisze:


reject_unknown_helo_hostname would indeed be too aggressive. but you
could use restriction classes and only call it if the sender is null (<>).

or you could run aggressive checks if the client has a "generic" reverse
dns. or in this particular case, simply reject *.rev.dynxnet.com with a
check_client_access:
rev.dynxnet.com REJECT blah blah
.rev.dynxnet.comREJECT blah blah
  


If I'll have any trouble with reject_unknown_helo_hostname sitewide I'll 
change it according to information above.
For now I'll have some time to think over BATV (full-blown or "poorman" 
versions) - each simplified solution has some disadvantages which on 
first sight are not good at my site (ex. changing submission port means 
to me reconfiguration of over 100 standalone PCs...).


Thank you for all support

Regards
Pawel Lesniak

Re: Backscatter with forged return-path

[Paweł Leśniak]

mouss pisze:

Paweł Leśniak a écrit :
  

mouss pisze:


reject_unknown_helo_hostname would indeed be too aggressive. but you
could use restriction classes and only call it if the sender is null
(<>).

or you could run aggressive checks if the client has a "generic" reverse
dns. or in this particular case, simply reject *.rev.dynxnet.com with a
check_client_access:
rev.dynxnet.comREJECT blah blah
.rev.dynxnet.comREJECT blah blah
  
  

If I'll have any trouble with reject_unknown_helo_hostname sitewide I'll
change it according to information above.



using reject_unknown_helo_hostname site wide is risky. problems will
happen when you will stop watching! (at least, this was my experience
although it was a few years ago).

if you still want to use it, you can:
- use DNSWL so that whitelisted clients are never blocked/deferred
- you can also have a local whitelist
- have a log parser that looks for 4xx because of unresolved helo, do
some checks, and possibly whitelist the client so that it is accepted at
the next retry.

of course, this assumes a 4xx code (this is the default).

  
OK, I was happy really too fast. Unfortunately after 24h we've started 
receiving backscatter from

well configured (in terms of DNS/RevDNS entries) servers.
The only fast solution right now I can see (and actually I started 
pointing higher) is URIBL_*_SURBL in
spamassassin. As all backscatters (which we are getting now) have those 
bad URLs, these tests

are doing their job quite well. I know this is ugly solution, but it works.
I've turned off reject_unknown_helo_hostname, as it's not doing what I 
hoped it will, while keeping

two other reject_unkown_*_hostname.
During first 24h I've found 3 IPs getting blocked (which I'd like to get 
mail from, even when they have configs
even worse than mine). The worst is I also have ~500 IPs which I can't 
tell from logs (sender, recipient, ip, helo)

whether I want those messages or not.


yes. that said, enable the submission service and start "migrating".
This is the recommended way.

note that if users access the server from mynetworks, you can use a NAT
redirection to divert traffic to the submission port. This can help
during the "migration".
  
Users are not in mynetworks (they have to authenticate). But I can set 
up redirection for traffic from my internal network.


Thanks again for helping


Pawel Lesniak

Re: User getting back scattered

[Paweł Leśniak]

body check
if /^[> ]*Received:/
/^[> ]*Received: +from +(beth\.k12\.pa\.us) / reject forged client 
name in Received: header: $1
/^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo 
+)(beth\.k12\.pa\.us)\)/ reject forged client name in Received: 
header: $2
/^[> ]*Received:.* +by +(beth\.k12\.pa\.us)\b/ reject forged mail 
server name in Received: header: $1

endif
/^[> ]*Message-ID:.* /^[> ]*Message-ID:.*@(beth\.k12\.pa\.us)/ reject forged domain name in 
Message-ID: header: $1


At least last part of rule is incorrect. Peaking at headers of your 
message to this mailing list we can see:


Message-Id: 

So this is probably not what you really want, to block massage 
containing this in body, because this way you'll block legitimate 
replies from mailer-daemon.
Have also a look at archives of this mailing list. I've started a thread 
on backscatter on january 26th and got some good ideas (replies) on how 
to resolve problem.



Pawel

Re: Sender-Recipient forged mail

[Paweł Leśniak]

MacShane, Tracy pisze:
  

-Original Message-
From: owner-postfix-us...@postfix.org 
[mailto:owner-postfix-us...@postfix.org] On Behalf Of itsramesh_s

Sent: Friday, 6 February 2009 4:25 PM
To: postfix-users@postfix.org
Subject: Sender-Recipient forged mail


Hi,

I have configured postfix postfix-2.4.5-2.fc8. all mail user are
getting forged mails as sender and recipient are same. we have
secondary mx i am sending both postconf output,

Please help me to stop forged mail.

Postconf -n of primary MTA   


smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_pipelining,
reject_unknown_recipient_domain, reject_non_fqdn_sender,
reject_unauth_destination



You could do with a whole lot more smtpd restrictions, such as
reject_non_fqdn_recipient, reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,  reject_unknown_sender_domain,
reject_unknown_reverse_client_hostname (or
reject_unknown_client_hostname, but this tends to give a lot of false
positives due to admins who can't configure DNS properly,
unfortunately).

If all your senders are sending from hosts in mynetworks, then the
easiest method is to do  "check_sender_access
hash:/etc/postfix/sender_access" after reject_unauth_destination (and
permit_mynetworks, of course), where /etc/postfix/sender_access is as
follows:

mydomain.comREJECT Mail from our senders must come from our
hosts
  

Well,
I'd change this part (from primary MX):

smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination, permit_mx_backup

by adding 
check_sender_access hash:/etc/postfix/sender_access

after permit_mx_backup
Contents also like Tracy wrote.
Of course while you are allowing mail from authenticated users and 
my_networks, it should allow all your users to send mail (not only from 
my_networks but also authenticated users from "outside").


Good idea is to take benefit from RBLs, like zen.spamhaus.org.
I also get good results with checking addresses whether they contain FQDN.
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
right after permit_sasl_authenticated and permit_mynetworks

And you could simplify your config. Ex. it's no use to have 
permit_sasl_authenticated in sender_restrictions if you have it in 
recipient_restrictions.
Probably the clearest way is to combine all rules from sender and 
recipient restrictions in smtp_recipient_restrictions - you'll have very 
good view of order of rules.



Pawel

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

João Miguel Neves pisze:

Charles Marcus escreveu:

Here's a link informing why indiscriminate use of SAV is bad, and what
it should be used for:

http://www.backscatterer.org/?target=sendercallouts
OK, I've finished reading and analyzing that text. My conclusion is 
that there's no reason not to use reject_unverified sender.


In this answer I'm assuming 1) the postfix implementation of SAV and 
that any implementation and 2) that MTAs implement the RFCs (so they 
have a configuration that matches, for instance, the Book of Postfix).


There are 3 claims in that text:

1) That by disabling VRFY, a sysadmin has decided to disable all kind 
of email address verification.


Most people disabled VRFY to prevent spammer tests for email 
addresses, nothing else. If you want to disable all tests for email 
addresses you accept all email for all email addresses, even 
non-existing ones and later discard the invalid ones. That's the only 
way to do it (and the reason why some of my clients are using 
catch-all addresses that they redirect to /dev/null).
Well, if you discard any message which can be "real" message (not 
containing viruses etc.) just with typos, you just have no users to 
complain they didn't get important emails. That's it. In that case 
(private SMTP with few addressess and small traffic) you won't probably 
get blacklisted. The other scenario (many users, big traffic) ends up 
with your server blacklisted.
Anyways - those clients which you mention, are in first scenario (few 
emails), or they don't use business cards and commercials in 
non-electronic forms, or there was no one to tell them what they are 
missing.

2) That a spammer can create a DDOS using SAV.

You'll get a connection per server to which those were sent (postfix 
caches the request, so it will only validate an email adress once).


SAV actually helps reduce the effect of the DDOS attack. In the 
non-SAV scenario, you get 30 million bounce messages. In the SAV 
cenario, each server does one check per email adress (that costs you 
less bandwidth and disk space than a Bounce message) and that single 
check will avoid several bounce messages.


That's not true. In some cases if you are checking envelope sender, you 
can see <>. How do you think you can deal with it? While you can get few 
thousands emails with forged return-path emails (existing or not - not a 
problem). Now imagine that your server is not the only one which 
received this amount of mails with same sender. Then you are performing 
DDoS.  Anyways - you should not bounce messages for non-existent users. 
You should rather reject them (and that's efficient).
And what's the point of having catch-all address when you discard those 
emails? Have on mind that you are still open to dictionary attacks. And 
in most cases spammers don't care if your email is correct or not. Still 
your emails are cool to be used for backscatter.

3) That SAV might create a loop.

The SAV check in postfix is done with the postmaster address by 
default. If the target server does the same check back, then the SAV 
server replies that postmaster is valid (assuming it's well-configured 
and RFC-compliant).


Have I missed anything?
Well, to be honest, I believe you did. If you will do many checks to the 
same server (have on mind large ISPs with many domains) with different 
emails, then probably your server will get blacklisted to send email 
from postmaster@ (at least). If you want explanation why, here it is: 
SMTP session to do SAV check is naither an email from individual to 
individual, nor message from receiver's system to sender. Of course it's 
also not wanted by sender, so in any case - it's spam and your server 
should be treated like any other spamming server. You hopefully 
understand my point of view. You don't have to agree - it doesn't matter.


Maybe this thread is a good reason to create BL containing servers doing 
large amounts of SAV checks? I'd be very happy if I could use such BL to 
reject emails from postmaster at those domains (and probably <> also).



Pawel Lesniak

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

mouss pisze:

no reason to overreact. I am not seeing SAV abuse (but I am seeing
backscatter and spam).
  
And I do under some circumstances. If I have SPF record, then I'm 
helping the other side to check if mail with sender from my domain is 
permitted or not. This means that sender already had to pass my tests 
and was permitted by my server to send mail. Why in hell would I give 
another resources to do checks which are *really* useless in such 
configuration? I know that SPF is not the cure for everything, but in 
war SPF vs SAV I prefer SPF which I can control rather than SAV which 
can be abused with backscatter.

let me fork a little: SAV on _header_ addresses is plain dumb:

Dec 15 11:25:33 imlil postmx/smtpd[23878]: NOQUEUE: warn: RCPT from
chlothar.bnv-bamberg.de[217.146.130.193]: Transaction logged:
PTR=chlothar.bnv-bamberg.de; from=
to= proto=ESMTP helo=

if you post to the spamassassin-users list, and you log transactions,
you'll see such probes.
  
Have you any clue whether they do those probes if sender's domain has 
SPF record? In case they do SAV if sender's domain is not using SPF/DKIM 
I'd say it's acceptable for me.


Pawel Lesniak

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

[Paweł Leśniak]

mouss pisze:

João Miguel Neves a écrit :
  

OK, I'll take that into consideration if I re-enable SAV.





if you re-enable SAV, do as much checks as you can. the minimum is
zen.spamhaus.org. but you can also use spamcop.

it would also be good to do it after greylisting, but this means your GL
server need to return a defer instead of defer_if_permit.

what you can also do is run a log parser that counts the SAV probes you
send, and disable the feature if some threshold is reached (rate limit
per client network, per sender domain, and global).  (an alternative is
a policy server that implements this, but a log parser is enough).

I was under the impression that you did it before zen check because the
log you posted has a client listed in zen. but I now realize it may have
been listed later.
  
And again my 5 cents. I think that people should take advantage of SPF 
and/or DKIM records. If you'll check DKIM/SPF then you could for example 
do SAV for clients/senders who are not allowed via SPF/DKIM or do not 
provide those records. I believe this change is no cost for you, and is 
saving some resources on both sides. Anyways whether you'll do SAV for 
"bad" hosts or just reject emails from them is your choice. But no one 
will blame you if you reject those emails, as you should be informed by 
administrator (in terms of SPF/DKIM records) which hosts are permitted 
to send (relay) - if you're given SPF record it should be correct, right?


Pawel

Re: rbl clients.

[Paweł Leśniak]

Victor Duchovni pisze:

On Thu, Feb 12, 2009 at 02:02:03PM -0500, Linux Addict wrote:

  

Please see below my smtpd_recipient_restrictions. On my rbl client list I
have multiple entries, but not sure how many of them actually maintained. Is
there one single place where I can find such a list. Any help is greatly
appreciated.



Replace all of them with just:

reject_rbl_client zen.spamhaus.org

If this still leaves you with way too much junk to filter with a content
filter, and you can afford to be more aggressive, add just

reject_rbl_client bl.spamcop.net

avoid all the rest, especially the ones long dead.

Make sure your DNS cache is not using an ISP upstream forwarder.

If your traffic is high enough, buy a SpamHaus data feed.
  

On my server I get following results in logs (last 4 days):
$ ~/dnsblcount /var/log/mail.1
zen.spamhaus.org3438
ips.backscatterer.org 98
hostkarma.junkemailfilter.com=127.0.0.2   28
bl.spamcannibal.org   17
cbl.abuseat.org3
=
Total DNSBL rejections:  3584

$ ~/dnsblcount /var/log/mail.2
zen.spamhaus.org6938
ips.backscatterer.org115
hostkarma.junkemailfilter.com=127.0.0.2   67
t1.dnsbl.net.au   33
bl.spamcannibal.org   13
dnsbl-1.uceprotect.net 3
bl.spamcop.net 2
=
Total DNSBL rejections:  7171

$ ~/dnsblcount /var/log/mail.3
zen.spamhaus.org   10810
hostkarma.junkemailfilter.com=127.0.0.2  164
ips.backscatterer.org 80
bl.spamcannibal.org   24
dnsbl.njabl.org7
dnsbl-1.uceprotect.net 4
cbl.abuseat.org2
=
Total DNSBL rejections: 11091


$ ~/dnsblcount /var/log/mail.4
zen.spamhaus.org   10875
hostkarma.junkemailfilter.com=127.0.0.2   98
bl.spamcannibal.org   25
ips.backscatterer.org 10
dnsbl.njabl.org2
cbl.abuseat.org1
=
Total DNSBL rejections: 11011


As you can see cbl.abuseat.org which is included in zen.spamhaus.org 
gives some more results than zen (actually it's simple - update takes 
some time).

backscatterer and spamcannibal are used only for <> and postmaster senders.
dnsbl-1.uceprotect.net gave me only false positives so it's turned off now.
I'm also using t1.dnsbl.net.au and bl.spamcop.net (this one I've got 
right after zen.spamhaus) - no results in last 4 days, but still testing.
I have a total of ~5-20k SMTP sessions per day which get to rbl tests. 
So after testing zen.spamhaus.org it's about 1 to 10k tests left to be 
done. And while I have local dns server it's even smaller number of DNS 
checks with BLs). I think that most of people here will say that it's 
(at least) stupid to have only ~0.1% more spams filtered with one more 
rbl check (with that low SMTP traffic).


Anyways before rejecting mails with any BL (besides those really "well 
known", like the two Victor gave), check if those won't give you too 
many false positives.


I'd also recommend to lower smtpd_recipient_limit from 300 to some 
reasonable amount, unless you really use that "large" bulk mailings.



Pawel

Re: user getting spoofed

[Paweł Leśniak]

Noel Jones pisze:

jeff donovan wrote:

Greetings

I have a user whos name is being spoofed by the spammers of the 
world. and her mailbox is getting flooded by legitimate Mailer 
Delivery notices.
Is there anything i can do for her besides change her account name ? 
I was thinking about a temporary regex to discard those notices. ( i 
know not the best but it may stem the tide ).


any assistance is welcome

-jeff


General suggestions for combating backscatter:
http://www.postfix.org/BACKSCATTER_README.html

You can use the ips.backscatterer.org to reject bounces (*NOT* all 
mail) from known backscatter sources.  Do this in 
smtpd_data_restrictions for compatibility with sender address 
verification.

# main.cf
smtpd_data_restrictions =
  check_sender_access hash:/etc/postfix/backscatterer

# backscatterer
<>  reject_rbl_client ips.backscatterer.org


I'd also recommend using rbl (like in above example).
<> reject_rbl_client bl.spamcannibal.org, reject_rbl_client 
ips.backscatterer.org
postmaster reject_rbl_client bl.spamcannibal.org, reject_rbl_client 
ips.backscatterer.org
MAILER-DAEMON reject_rbl_client bl.spamcannibal.org, reject_rbl_client 
ips.backscatterer.org


I'm getting quite good results with backscatter using those two BL 
servers above.
Unfortunately I also had 1 user getting lots of backscatter. What I've 
found it's useful to do some body_checks.
Have a look if there's something common in some of those annoying 
messages, and set sth like:

body_checks = pcre:/etc/postfix/body_checks
Part of my body_checks file:
if /^[> ]*Received:/
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\(\[[0-5,7-9](.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\(\[6[0-6,8-9](.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\([0-5,7-9](.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\(6[0-6,8-9](.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\(unknown(.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.CUSTOMER\.VPLS\.NET.\([a-b,d-z,A-B,D-Z](.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> 
]*Received:.from.(.*)\(HELO.CUSTOMER\.VPLS\.NET\).\([0-5,7-9](.*)\)(.*)/

   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> 
]*Received:.from.(.*)\(HELO.CUSTOMER\.VPLS\.NET\).\(6[0-6,8-9](.*)\)(.*)/

   REJECT Backscatter from CUSTOMER.VPLS.NET
/^[> ]*Received:.from.(.*)\((.*)helo=CUSTOMER\.VPLS\.NET\)(.*)/
   REJECT Backscatter from CUSTOMER.VPLS.NET
endif

I was getting lots of backscatter sent from hosts claiming to be 
CUSTOMER.VPLS.NET, and then I found above rules to help me a lot (they 
are far from ideal, but they just work for me).
Maybe you can also build body_checks to stop backscatter one of your 
users is getting.



Good luck,

Pawel

Re: whitelisting trusted addresses

[Paweł Leśniak]

Hello,

Did you try dnswl.org ?


Pawel

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-03 08:25, Dave Johnson pisze:

Hi all

Is there anyway of stopping the from "j...@foo.com" 
 to "j...@foo.com" spam attacks?




Hi

Without knowing your config it's hard to say what are you already doing.
Are you using SASL authentication? If not, have a look here: 
http://www.postfix.org/SASL_README.html#server_sasl
To get really useful help (not just speculations) you have to read 
http://www.postfix.org/DEBUG_README.html#mail


Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-03 17:46, Noel Jones pisze:
Some people reject their own domain from outside, unauthenticated 
clients, but this will certainly reject some amount of legit mail.


Could you write a little bit how is it possible to reject legit mail by 
rejecting unauthenticated clients when all users do use SASL 
authentication or are in my_networks?



Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-03 23:34, MacShane, Tracy pisze:


We have a very clear policy that users are only permitted to relay mail
from our networks. If they are sending from home, they use webmail.
We've had one or two instances where external organisations have used
some kind of auto-reply mechanism which purports to send from our users,
but we simply tell them to fix the sender address. We use a sender
access map to reject the spurious senders that aren't coming from
my_networks. You can use warn_if_reject to test the impact of this
measure for a few days or weeks.

main.cf
==
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_non_fqdn_sender,
   check_sender_access hash:/etc/postfix/sender_access


# cat /etc/postfix/sender_access
ourdomain.com   REJECT
ourdomain.gov.au  REJECT
   
So you too advocate (if I clearly understand you) my point of view, 
where those "legit mails", which Noel was talking about,

are just misconfigurations of others' servers.
I believe that we share opinion that restricting own users to sending 
from my_networks and/or authenticated clients
works perfectly to stop getting spam from u...@example.com to 
u...@example.com.


Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-03 18:41, Noel Jones pisze:
Some legit "reminder" type services, some meeting notifications, and 
other legit mail might arrive with you as the sender.  Maybe not best 
practices, but it's legit mail and such a policy will reject it.
Why would someone want to fake sender address? Is this really legit mail 
when one has (envelope!) sender address spoofed? I've no idea why should 
I get reminder from myself. If xyz is this service provider I want to 
get reminder from s...@xyz.


You can send yourself mail via eg. gmail or your home ISP with your 
postfix domain as sender address.  Some people really do this.
And why would I do that? If my ISP would restrict to send only via their 
SMTP server, I'd use webmail. And I have no idea why would one allow 
relaying via their SMTP server for everyone. And if not for everyone, 
then ISP should do address rewriting for their users. That's it. And 
that still doesn't change my point of view - broken configuration 
doesn't always give you legit mail.
If one still wants to use other SMTP server to send mail with spoofed 
address, why just not add this SMTP server's IP to my_networks?


The "some amount" of legit mail you will reject is highly dependent on 
your users. Some sites will see quite a bit, others very little.  Some 
people consider this a horrible idea, others a useful policy with an 
acceptable risk.  You get to pick which side of the fence you live on.
I cant's see any risk anyways, not just in place. And it's possible that 
zen BL will stop more "legit" mails (depends on what one means by "legit 
mail", maybe there are people who read those "I'll give you $1billion" 
mails). If I'm wrong, please point it out, let me learn.



Pawel Lesniak

Re: FW: Spam attacks

[Paweł Leśniak]

Hi all

Just to clarify some points

They are running an IMAP server with SASL login for remote users

IMAP let's you get mail from your account. So it's really not related to 
your problem.
You'd have to use SMTP authentication so when one wants to send mail 
from u...@example.com to anotheru...@example.com or u...@example.com, 
one has to use IP inside my_networks or has to authenticate using SASL 
authentication with SMTP session. So this will certainly stop spam from 
u...@example.com to u...@example.com, but please read whole thread - you 
should be aware of  possible risks.


Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

I can state with authority that mail with sender==recipient is not 
universally 100% spam, and such a policy would likely have a much 
higher false positive rate than zen. You can argue it's a 
misconfiguration of the sender, but a mail admin's job is to receive 
legit mail. but you're welcome to reject mail on any basis you see 
fit. a small site can probably implement this policy with no 
noticeable problems.


Sure. I'm sending myself emails sometime. But I'm using server which is 
permitted to send with address from my domain. So that's surely not 100% 
spam when sender eq recipient.
But then we come to definition of spam. It's in simple words unwanted 
message. And when someone spoofs my email address, it's certainly not 
obeying with my image of legit mail. If I'm calling someone, I'm not 
presenting myself as John Johnson. Maybe some people do...
I think you can't give any example that one ^have to^ use my email 
address when sending msg to me. You didn't convince me that I'm 
rejecting any legit mail by rejecting not authenticated users.


Also IMHO I'll get much more "false positives" with zen then with 
authentication if for example I'd be interested in getting money and 
medicines offers. We get here to definition of "false positives" which 
can be very different for different customers. And that leads as to 
another problem whether we consider authentication at customer level (or 
server serving SMTP for just single company) or site-wide (in terms of 
many customers with single configuration).


Coming back to large ISPs. After checking few "emails for everyone" 
providers in Poland I can tell that all of them do relay only for 
domains they serve. And it's not common for Internet Access Providers to 
block outgoing connections to port 25, still I mean here, in Poland. So 
I think that situations pointed by you are rather rare. I don't know of 
any, so I'm fine with rejecting 0 legit mails at my place by using smtp 
authentication.


Pawel Lesniak

Re: Messages Are Refused

[Paweł Leśniak]

I am noticing that for some reason every time a specific user on my
domain attempts to email a particular domain, the messages are always
queued up. They don't ever appear to send for some reason and I
checked the logs which don't really give any specific reason why he
can't send email to this domain. Do you guys know by looking at what I
can see on my end if this problem is caused by something on my end?

When I go to my Postfix email server, I checked to see what it
resolves as follows:

mail:~# host je.jfcom.mil
je.jfcom.milA   140.32.76.138
   

Looks fine. Same IP here.
It looks like they have network problem - I can't connect to their SMTP 
server as well.

Maybe it's temporary problem.


Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

On Wed March 4 2009 08:48:18 Paweł Leśniak wrote:
   

But then we come to definition of spam. It's in simple words unwanted
message.
 


Too simple, and not correct. The true definition of spam is UBE:
unsolicited bulk email. Most spammers put out messages that a tiny
percentage of recipients want to see. It's how they keep making money
at it.
   
And where do you see the difference between unwanted message and 
unsolicited bulk email? Word bulk here does not matter in terms of 
single email address - you don't know (often) if this is one message of 
many sent or just a single mail, as long as given sender gets 
blacklisted or you start getting same mail at many different addresses.

Postmasters who fail to understand what spam is contribute to the
problem, which is this: email has become nearly unusable for many
people, and would be unusable for everyone without sane strategies to
control the spew. I bet 95% of all SMTP traffic is abuse.
   

At my servers it's about 90-95% percent of connections which get rejected.


Also IMHO I'll get much more "false positives" with zen then with
authentication if for example I'd be interested in getting money and
medicines offers. We get here to definition of "false positives"
which can be very different for different customers. And that leads
 


For the most part, I don't care what the end user thinks, for reasons
implied above. If they solicited email from a legitimate (i.e., not
listed on SBL and not using zombies) bulk sender, they'll get it. If
they solicited email from a spammer, oops, it's blocked.

We all owe it to the Internet to limit spammers' access to our
clue-deprived users who might otherwise help keep them in business.

   

true

I try to explain it to them. No, it's not easy. No, I am not managing
any large sites at the moment, but if I was, I'd put up explanations
with links on a http://postmaster.example.com/ Web site.

Most people who claim that Zen gives "false positives" are not using
reject_rbl_client properly. Obviously, you do not reject_rbl_client
before permit_sasl_authenticated. But in your case I don't know what
you're saying. I think the issue of authentication that you bring up
might be irrelevant, except perhaps for the narrow "issue" of sender
equals recipient. I haven't noticed a significant problem with such
spam, which is probably attributable to Zen.
   
I'm not saying zen gives "false positives" which I (or better users of 
my servers)  think are not spam. But if one says that mail sent with 
spoofed sender is correct then it's not fine with me.
I do not allow mails from client addresses without DNS entries (why 
don't they use correctly configured mailserver), etc. One can say that 
I'm rejecting many false positives. Maybe. But I'm rejecting those 
messages. If sender wants to send legitimate email to me and gets 
rejected, he should get reply from his server about rejection. If this 
is the case, then "the ball is on his side". In terms of business mails, 
one will say that after rejection, the other side will just think we are 
not worth cooperation. That's not true, because it's better to get 
rejection instantly then wait few days while recipients finds the 
message in spam folder for example.


Looking at first email in thread carefully you'd see that Dave has (or 
had) problem with spam sent from j...@foo.com to j...@foo.com. And that's 
the case where authentication will do the job perfectly - IMHO way 
better then zen.


Pawel Lesniak

Re: postconf -n suggestion

[Paweł Leśniak]

I was just talking about something that would make it easier when
someone was asking for help on the list... I don't think the above will
quite accomplish that...

   
In many cases (I'm not gonna do statistics) new users do not post their 
questions correctly - often we can see 2nd message in thread asking for 
more information according to MAIL_DEBUG readme.
So I think that making changes to postconf -n output are useless. If one 
will manage to read MAIL_DEBUG, one will also be able to have a look at 
postfix version and other system-related informations. If not, certainly 
one should not do any changes to mail server. Honestly.


Pawel Lesniak

Re: postconf -n suggestion

[Paweł Leśniak]

W dniu 2009-03-04 20:53, Charles Marcus pisze:

Irrelevant. There is nothing wrong with simplifying things...
   
Simplifying does not mean changing behavior. As Wietse said, postconf -n 
shows only setting from main.cf. So adding values from outside main.cf 
is not simplifying at all.

By your argument, there is no need for the postconf tool at all...
   

Never said anything like that.

Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

On 3/4/2009, PaweB Le[niak (warl...@lesniakowie.com) wrote:
   

Looking at first email in thread carefully you'd see that Dave has
(or had) problem with spam sent from j...@foo.com to j...@foo.com. And
that's the case where authentication will do the job perfectly - IMHO
way better then zen.
 


You do realize that if you did that you wouldn't be able to receive your
own messages from mail lists such as this one, correct?

   

How come?

Mar  4 20:50:50 lola amavis[15332]: (15332-05) FWD via SMTP: 
 -> ,BODY=7BIT 
250 2.6.0 Ok, id=15332-05, from MTA([127.0.0

.1]:10025): 250 2.0.0 Ok: queued as EACA754205

And here restrictions (only recipient - not using any other):
smtpd_recipient_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_sender, 
reject_non_fqdn_recipient, reject_unknown_sender_domain, 
reject_unknown_recipient_domain, reject_invalid_hostname, 
reject_unauth_destination, reject_unlisted_sender, check_sender_access 
hash:/etc/postfix/restricted_senders.map, reject_sender_login_mismatch, 
check_client_access pcre:/etc/postfix/check_client_fqdn.pcre, 
check_recipient_access hash:/etc/postfix/restricted_recipients.map, 
reject_rbl_client zen.spamhaus.org, check_greylist


/etc/postfix/restricted_senders.map:
lesniakowie.com 554 Prosze wlaczyc autentykacje SMTP / Please enable 
SMTP authentication


I'm getting all messages without problems. Also those sent by myself.

Pawel Lesniak

Re: Blocking a domain and user

[Paweł Leśniak]

W dniu 2009-03-04 21:32, Jim McIver pisze:
I have Postfix 2.1 on Freebsd 4.10 and am having trouble blocking 
email from a domain.


Here is a snipet of the postqueue -p:

DF6A927D   3512 Tue Mar  3 18:42:35  MAILER-DAEMON
(connect to mx1.mail.yahoo.co.jp[124.83.183.240]: server dropped 
connection without sending the initial SMTP greeting)

megu0327_he...@yahoo.co.jp

D5EFB277   3508 Tue Mar  3 18:42:28  MAILER-DAEMON
(connect to mx3.mail.yahoo.co.jp[203.216.247.184]: server dropped 
connection without sending the initial SMTP greeting)

megu0327_he...@yahoo.co.jp

D870B221   3248 Tue Mar  3 15:03:34  MAILER-DAEMON
(connect to mx5.mail.yahoo.co.jp[203.216.243.173]: server dropped 
connection without sending the initial SMTP greeting)

maria_rosmarinus0...@yahoo.co.jp

DA5AC227   3583 Tue Mar  3 14:46:26  MAILER-DAEMON
(host mx3.mail.yahoo.co.jp[124.83.155.153] said: 451 VS14-RT5 Mailbox 
bounce arrival rate exceeds system limit (#4.2.2) 
x_lily_05...@yahoo.co.jp (in reply to RCPT TO command))

x_lily_05...@yahoo.co.jp

D11AD314   3248 Wed Mar  4 08:21:42  MAILER-DAEMON
(host mx3.mail.yahoo.co.jp[124.83.155.153] said: 451 VS14-RT5 Mailbox 
bounce arrival rate exceeds system limit (#4.2.2) 
maria_rosmarinus0...@yahoo.co.jp (in reply to RCPT TO command))

maria_rosmarinus0...@yahoo.co.jp

D48452DB   3250 Wed Mar  4 11:39:04  MAILER-DAEMON
(host mx2.mail.yahoo.co.jp[203.216.243.170] said: 451 VS14-RT5 Mailbox 
bounce arrival rate exceeds system limit (#4.2.2) 
maria_rosmarinus0...@yahoo.co.jp (in reply to RCPT TO command))

maria_rosmarinus0...@yahoo.co.jp

I would like to block the .co.jp so it doesn't pile up in postqueue.
This seems like your email address has been used as sender_address with 
some spam rejected by yahoo.co.jp (just a guess). Anyways your 
MAILER_DAEMON tries to send bounces to yahoo.co.jp. You'd have to check 
what's inside those bounced messages to find out what's the real 
problem, I mean why your mailserver is generating those bounces.
You could reject those messages by rejecting recipients from 
yahoo.co.jp. but this is not recommended.

2nd:
I also receive over 400 messages daily from "u...@domain.com". The 
messages never go anywhere, they just pile up in the postqueue and I'd 
like to keep the postqueue -p cleaned out.


Snippet from maillog:

Mar  4 00:09:21 mail postfix/smtpd[36633]: NOQUEUE: reject: RCPT from 
unknown[89.218.164.251]: 554 : Sender address 
rejected: Access denied; from= 
to= proto=SMTP helo=<89.218.164.251.metro.online.kz>
Mar  4 02:41:25 mail postfix/smtpd[38622]: NOQUEUE: reject: RCPT from 
unknown[86.123.168.197]: 554 : Sender address 
rejected: Access denied; from= 
to= proto=SMTP 
helo=<86-123-168-197.brasov.rdsnet.ro>
Mar  4 02:59:03 mail postfix/smtpd[39694]: NOQUEUE: reject: RCPT from 
unknown[92.83.230.6]: 554 : Sender address rejected: 
Access denied; from= to= 
proto=SMTP helo=


Looks fine. You are rejecting mails from u...@domain.com (and that obeys 
with your config check_sender_access 
hash:/usr/local/etc/postfix/sender_access). You shouldn't see those in 
queue.


Pawel Lesniak

Re: Spam attacks

[Paweł Leśniak]

W dniu 2009-03-05 06:30, Mihira Fernando pisze:

Have you ever tried sending an e-greeting to someone via 123greeting.com or
some other similar site ?
   

You're definitely right - I didn't use that one before.
Look what I get in logs:
Mar  5 09:41:50 lola postfix/smtpd[20278]: warning: 72.233.20.39: 
address not listed for hostname www.123greetings.com

So they are surely doing something nasty...

Anyways:
Mar  5 09:41:52 lola postgrey[22558]: action=greylist, reason=new, 
client_name=unknown, client_address=72.233.20.54, 
sender=eca...@123greetings.com, recipient=pa...@lesniakowie.com


So, I have really no idea why are you all advocating that some services 
use MY EMAIL ADDRESS as ENVELOPE SENDER. It's something what should 
never be done. And I really know no site which does something that bad. 
End of story.


Discussion went far away from postfix, and some of you are trying to put 
in my mouth words I never said. It's my last post in this subject.



Pawel Lesniak

Re: Sender vs recipient restrictions.

[Paweł Leśniak]

W dniu 2009-03-18 14:23, Costin Guşă pisze:

On Wed, Mar 18, 2009 at 3:11 PM,  wrote:
   

I've been reading today about;

reject_unknown_sender_domain

and I'm wondering if it is only allowed under 'smtpd_sender_restrictions'
whereas I've had it under 'smtpd_recipient_restrictions'. Is this correct?

thanks,
Chas.
 


all smtpd_recipient_restrictions can appear in smtpd_sender_restrictions.
   
Wrong. As SMTP session has MAIL FROM before RCPT TO, you can have 
sender_restrictions in smtpd_recipient_restrictions, but not vice versa 
(of course you can, but it'd be useless) - recipient is not known during 
smtp_sender_restrictions part.



from man 5 postconf:

smtpd_sender_restrictions (default: empty)
Optional  restrictions that the Postfix SMTP server applies in the con-
text of the MAIL FROM command.
   

Clearly stated right where you pointed.

Pawel Lesniak

Re: Backscatter

[Paweł Leśniak]

W dniu 2009-04-04 20:09, LuKreme pisze:
I've seen an increase in backscatter emails recently. Perfectly valid 
headers (AFAICT)


Return-Path: <>
X-Original-To: kr...@kreme.com
Delivered-To: kr...@covisp.net
Received: from mail9.webair.com (mail9.webair.net [74.206.236.69])
by mail.covisp.net (Postfix) with ESMTPS id 4FC10118B5B0
for ; Sat,  4 Apr 2009 00:18:38 -0600 (MDT)
Received: (qmail 45760 invoked for bounce); 4 Apr 2009 06:18:36 -
Date: 4 Apr 2009 06:18:36 -
From: mailer-dae...@mail9.webair.com
To: kr...@kreme.com
Subject: failure notice
Message-Id: <20090404061838.4fc10118b...@mail.covisp.net>


(I did just update this spf record to "v=spf1 a mx 
ip4:75.148.117.94/29 ~all" which I expect will help some)


Is there some sort of strategy I can implement that will reject a good 
portion of these kinds of messages? What are other people doing to 
deal with backscatter? I read up on SRS, but it doesn't sound like a 
great idea.



I'd recommend using rbl checks specified for this:
backscatter.map:
<> reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org
postmaster reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org


Add
check_sender_access hash:/etc/postfix/backscatter.map
at the very last of RBLs in smtpd_recipient_restrictions (or other 
restrisctions if you prefer). For sure you should also read info on 
those blacklists.


IP you've provided as source of backscatter is listed in backscatterer.org.

Moreover, SPF won't help you much, because other mailserver admins would 
have to check it, and it's rarely supported.


Pawel Lesniak

Re: Backscatter

[Paweł Leśniak]

W dniu 2009-04-05 04:27, Sahil Tandon pisze:

On Sat, 04 Apr 2009, LuKreme wrote:

   

On 4-Apr-2009, at 16:02, Noel Jones wrote:
 

Best in smtpd_data_restrictions so you don't reject sourceforge and
others sender verification probes.
   

Is there anything I need to be concerned about having/not having in
smtpd_data_restrictions?  it is currently commented out.  if I simply
put:

smtpd_data_restrictions =
 reject_unauth_pipelining,
 reject_rbl_client ips.backscatterer.org,
 reject_rbl_client bl.spamcannibal.org
 permit
 


The trailing permit is unnecessary.  And some people worry about blocking
legitimate mail from sites listed on those RBLs.  If you share that fear, you
could use an access(5) table to limit the RBL lookups (and rejections) only
to null envelope senders.
   
You should NEVER use ips.backscatterer.org as global RBL. You'll block 
legitimate mails for sure. The question is only how many.
Also using bl.spamcannibal.org for all senders is not very safe. Before 
using ANY RBL read what it actually does.


From backscatterer.org site:
"Listing Policy is quite simple. Every IP which backscatters or does 
sender callouts will be listed the next 4 weeks here."
So every host which does email verification would be entirely blocked, 
and that's almost surely not what one would want.

And on more citation:
"Unfortunable many and also big providers do still backscatter. They are 
flooding you with bounces but will almost always send real mail too.
As long as you are not a BOFH nor having the intention to boycott such 
servers we strongly recommend to use ips.backscatterer.org in SAFE MODE 
to prevent false positives.
SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or 
postmaster only.
Used in safe mode ips.backscatterer.org will protect you against 
misdirected bounces and sender callouts while you can not loose any real 
mail."


A bit different situation is with spamcannibal. It's "normal" RBL, but 
in my place it was giving 10 to 50 false positives daily. A month ago 
spamcannibal was stopping some backscatter. Now I get rarely any hits, 
but it's used as the very last RBL to check emails from <> ans 
postmaster. Soem citation from their site:


"The ONLY way you can get into SpamCannibal's database is by sending 
spam or virus ladened email to our mail servers!
SpamCannibal does not block email access except for IP addresses and 
ranges that have sent or relayed what we believe to be spam or other 
unsolicited email directly to our email servers. SpamCannibal uses its 
database to block access by IP addresses ONLY for its own mail servers, 
however, the database we use for that purpose is freely available for 
anyone to look at and use as they see fit. "


So if one would do a typo in email and got into their honeypot, the host 
(or subnet) is getting blacklisted. For me it's much to simple to get 
blacklisted at spamcannibal.org.



Pawel Lesniak

Re: Sender with invalid domain

[Paweł Leśniak]

W dniu 2009-04-13 22:46, mouss pisze:

does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?
   

According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name.  The consequences of 
this are becoming more and more obvious.  Many services available on the 
Internet will not talk to you if you aren't correctly registered in the 
DNS.
Make sure your PTR and A records match.  For every IP address, there 
should be a matching PTR record in the in-addr.arpa domain.

(...)

Assuming that spam is a global problem, and above RFC is something to 
obey with, it's not really important how many spams we'll block with 
reject_unknown_sender_domain. If message is blocked with 
reject_unknown_sender_domain, it means sender's server has some problem 
with DNS configuration. It's of no cost to configure DNS records for 
mailserver, and it makes lots less questions to zen. If mailserver's 
admin doesn't care about DNS entries I don't feel any need to care about 
emails coming from this mailserver. Fortunately all large public 
mailservers we're getting emails from have DNS records set up correctly.

On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
2466 x blocked using zen.spamhaus.org
As given above I need less than half of questions to zen RBL. Of course 
these numbers can be quite different depending on configuration and type 
of email traffic.


In my opinion, *if* one can afford loosing some legitimate mails from 
hosts without correct DNS entries, reject_unknown_* rules are worth 
using. Still if mail gets rejected, sender has possibility to ask 
his/her mailserver's admin to solve the problem.


Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze:

They are retarded. mail.charite.de is listed in it.
   

You're definitely not right.
Testresult for 141.42.4.200:

This IP IS CURRENTLY NOT LISTED in our Database.

B U T, it was listed in the past !

History:
2008/05/13 08:49listed
2008/06/10 09:30expired
2008/07/08 09:38listed
2008/08/22 11:30expired
2009/03/02 17:00listed
2009/04/12 13:07expired

If they send too many bounces, or do SAV, they are listed on 
backscatterer.org. That's simple.


Further - BECAUSE they are sending too many bounces it's quite good to 
stop receiving bounces from them.


Anyways, I've found that backscatterer.org is able to stop large flows 
of backscatter if they happen. When I was getting backscatter from many 
different IPs, backscatterer.org was not helping at all. But that's when 
body_checks work perfectly. As long as I'm a small site with ~10-20k 
SMTP connections daily, I'm fine with this configuration. Also I've 
found that 2 months after starting to use body_checks, the number of 
rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More 
precisely number of rejects lowered from ~850k in january to ~410k in march.


Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 11:56, Rod Whitworth pisze:

Oh dear, that's all really too much trouble. I have OpenBSD's spamd
running in front of my MTA. A script checks all greylisted entries for
invalid recipients with<>  sender and tarpits them.
   
If mail goes to invalid recipient it can be *rejected*. It's not really 
dependent on sender.



You cannot have a legitimate bounce going to an invalid sender for
bleedin' obvious reasons. So stick it to 'em.
   
I hope you mean recipient not sender. Are you sure that null sender is 
only used in bounces?



It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!
   
Could you explain how? If you greylist those mails instead of rejecting, 
you are getting additional SMTP connection(s). If you reject them, they 
are discarded. What am I missing?

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device
   

Check your storage.

Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 13:54, Rod Whitworth pisze:


Remember I did say that I was applying this to "null sender to
non-existing recipients" (who were purported to be the original
senders). We have about 60 spamtrap addresses. Most invented by
spammers.
   
I'd imagine somewhat better usage of spam-traps then grey-jail. And if 
it's "system-wide" - read on.

Are you sure that null sender is only used in bounces?
 


What else?
   

- SAV
- Auto-replies   (...)Since in most cases it is not appropriate to 
respond to

   an automatic response, and the responder is not interested in
   delivery status messages, a MAIL FROM address of <> MAY be used for
   this purpose.(...)  RFC3834
- Any type of automated notifications (...)In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and nondelivery notifications), the
   reverse-path may be null (see section 3.7).(...)  RFC2821


It wastes resources on all the misconfigured bounce-instead-of-reject
dummies out there and places no load on my lovely Postfix server. Heh!

   

Could you explain how? If you greylist those mails instead of rejecting,
you are getting additional SMTP connection(s). If you reject them, they
are discarded. What am I missing?
 


They are detected whilst they are in the greylist and then they are
grey-trapped (tar-pitted in other words)
   
IMHO: You are wasting also your resources, and you are slowing down the 
network. While it's
almost sure the other side will not correct configuration, the prize is 
smaller than the price.

Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device

   

Check your storage.
 


Check the population of /earth for yourself ... ;-(

   

There's still some room ;-)

Pawel Lesniak

Re: Sender with invalid domain

[Paweł Leśniak]

W dniu 2009-04-14 23:00, mouss pisze:

Paweł Leśniak a écrit :
   

W dniu 2009-04-13 22:46, mouss pisze:
 

does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?

   

According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name.  The consequences of
this are becoming more and more obvious.  Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS.
Make sure your PTR and A records match.  For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
(...)

Assuming that spam is a global problem, and above RFC is something to
obey with, it's not really important how many spams we'll block with
reject_unknown_sender_domain.
 


I disagree:
- I prefer to avoid dns checks if they don't bring me much
   

Look at numbers below. I think they bring a lot.

- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
   
Well. it depends on type of service. If I were an ISP, I think I'd take 
more care to avoid getting "false positives". As long as these are not 
RFC conformant, I won't call them legitimate emails.

- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
   
Well, I do not agree with that. It's just one more DNS query from my 
host. It's far less offensive then sending single email to this site.

- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.
   
You can't cure all sites your server is talking to. So you have to 
choose what you believe is best for you.

If message is blocked with
reject_unknown_sender_domain, it means sender's server has some problem
with DNS configuration. It's of no cost to configure DNS records for
mailserver, and it makes lots less questions to zen. If mailserver's
admin doesn't care about DNS entries I don't feel any need to care about
emails coming from this mailserver.
 


possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
  this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...
   
But these recipients care about amount of spam they get. If my server 
rejects some mails, the other side has to choose if they want me to get 
their mail or not. If there are not enough rules to stop spam, we have 
to obey with what we have (RFCs).



Fortunately all large public
mailservers we're getting emails from have DNS records set up correctly.
 


and spammers seem to forge valid addresses, so the check looks useless
to me.
   

How do they forge a client DNS A records consistent with PTR records?

On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
 


these also reject legitimate mail. YMMV.
   
I'd call those "legitimate mail". Server *should* have DNS records. If 
client address has no DNS enrtries, it's RFC-ignorant.

In my opinion, *if* one can afford loosing some legitimate mails from
hosts without correct DNS entries, reject_unknown_* rules are worth
using. Still if mail gets rejected, sender has possibility to ask
his/her mailserver's admin to solve the problem.
 


it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.
   

I do agree with your last sentences in 100%.

Pawel Lesniak

Re: A better backscatter killer?

[Paweł Leśniak]

W dniu 2009-04-14 23:11, mouss pisze:

Ralf Hildebrandt a écrit :
   

* MacShane, Tracy:

 

Then you won't receive some genuine messages, both bounce and
non-bounce.

Try the ips.backscatterer.org RBL; it works well for us.

http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html
   

They are retarded. mail.charite.de is listed in it.

 


and I guess postfix members would be bothered to block:
camomile.cloud9.net[168.100.1.3]
english-breakfast.cloud9.net[168.100.1.7]

$ host 3.1.100.168.ips.backscatterer.org
3.1.100.168.ips.backscatterer.org has address 127.0.0.2
$ host 7.1.100.168.ips.backscatterer.org
7.1.100.168.ips.backscatterer.org has address 127.0.0.2

so if one uses this list, then
- use a whitelist (dnswl and possibly local WL)
- use it in smtpd_data_restrictions to avoid blocking SAV sources. while
you may hate SAV, it's different than backscatter.
   

I think that you're missing something.
I'm getting emails from this list as:
 -> 
Where's the place where emails would be rejected? Is this list doing SAV?
I'd even ask - is ANY list doing SAV? It's hard for me to imagine 
sending thousands of emails to users who had already confirmed email 
address during "registration".


Pawel Lesniak

Re: Sender with invalid domain

[Paweł Leśniak]

W dniu 2009-04-14 23:47, mouss pisze:

Paweł Leśniak a écrit :
   

W dniu 2009-04-14 23:00, mouss pisze:
 

[snip]
and spammers seem to forge valid addresses, so the check looks useless
to me.

   

How do they forge a client DNS A records consistent with PTR records?
 


I meant they use forged sender addresses where the domain is valid. for
example, you may get spam with the sender set to.

   
Sure. If this will be sent from host without correct DNS entries it 
could be blocked with reject_unknown_*.

Anyways - question was about sender with *invalid* domain.

Pawel Lesniak

Re: Now OT. Terminating thread (was Re: A better backscatter killer?)

[Paweł Leśniak]

W dniu 2009-04-15 04:21, Rod Whitworth pisze:

--Original Message Text---
*From:* Pawe+‚ Le+›niak
*Date:* Tue, 14 Apr 2009 14:50:57 +0200
8>< snip-
I don't like top-posting but..
Due to your message formatting it is not possible for someone to 
easily see who said what in your reply. So simply for the benefit of 
others who may have had a passing interest, I'll make closing comments.
Talking about formatting - try to use somewhat newer client, with good 
message formatting. I have no problem to follow the thread.
All talk about RFCs in your message is irrelevant because messages 
from the null sender addressed to a fictitious recipient will NEVER be 
delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it 
never is as it contemplates things like sending virus notifications. 
Echhhk!


Have a look at http://www.postfix.org/bounce.8.html. Specially part 
STANDARDS. So it looks like RFC3834 IS a standard indeed.
So we trapit <> to invalid addresses and reading the logs shows that 
the probability of those messages being bounces from servers 
configured by amateurs is something like .77.



You can do whatever you want. But do not enforce others to break RFCs.
Talking about amateurs ... I do agree with that. But you won't do any 
good by messing. It would give better effect if you'd report them to 
some RBLs. If they get blacklisted with zen, they'll have to think over 
their configuration.
You have no idea how little load this places on our firewall. It is 
not even measurable when there is a spambot storm in progress. It does 
not consume any Postfix resources. It also seems that the tarpitting 
we do on other spammy senders is noticed by some of them as the number 
of trapped IPs at any instant is now about a quarter of what it was a 
year ago.


We don't slow down our network by tarpitting. The sender gets 1 char/ 
4 seconds and typically gives up after about 1500 seconds with the 
settings I use.


I did not mean your network. If there were many sites like your, it 
would be simple to fill up network attacked by few spambots. Have you 
ever thought that some sites share network connection?


Of course it gives up after first limit (client or server side) occurs. 
So it can be 300 seconds when sender stops (5 minutes limit is proposed 
in standard), or any other limit configured at the other side.
For more info see 
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html


And that's all folks! Back to lurking for me.

One more thing... you forgot to comment the part about what kind of 
emails can be sent with null sender address.

- SAV
- Auto-replies- -  (...)Since in most cases it is not appropriate to 
respond to

  an automatic response, and the responder is not interested in
  delivery status messages, a MAIL FROM address of <> MAY be used for
   this purpose.(...)-  RFC3834
- Any type of automated notifications (...)In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and nondelivery notifications), the
   reverse-path may be null (see section 3.7).(...)-  RFC2821

Still - you can do whatever you want.

Pawel Lesniak

Re: Question regarding SPF

[Paweł Leśniak]

W dniu 2009-04-17 08:50, Kammen van, Marco, Springer SBM NL pisze:


Hi All,

We recently took over a company that used SPF.

Because our e-mail infra is way more complicated than theirs and we 
have tons of external parties who send mails using our domains, we 
decided long ago not to use SPF.


Now they say that %5 of their mailings don’t arrive at customers 
anymore, and say this is because we removed their SPF records..


I’m no expert on SPF but as far as I understand it only checks if a 
sender is ‘allowed’ to send using that domain, so no relation what so 
ever on dropping mail from parties that don’t use SPF…

Or am I missing something?

It might be their IP's are on some blacklist and while they've had SPF 
record their emails were not checked in (some) RBLs. There's no such 
rule, but one can configure something like that.
Also it can be related to mail content, or amount of emails per piece of 
time to the same server. You could think of SPF usage like some kind of 
whitelisting, but that's dependent on one's configuration at client's 
side (the side which uses SPF record, not the one provides it).


For sure there's no straightforward relation between not using SPF and 
emails being rejected.


Maybe you've got some more information from logs why emails are being 
rejected?


Pawel Lesniak

Re: Max Size Not Working Correctly?

[Paweł Leśniak]

W dniu 2009-04-23 17:14, Rick Duval pisze:

You are truncating all the long logfile records.

Wietse

 


Sorry I didn't even realize that was happening. I dl'd the file and
copied and pasted instead of grabbing from putty which I guess was
only grabbing the screen.


Apr 22 13:52:55 vps04 postfix/qmgr[28236]: B3E982010001:
from=, size=14072292, nrcpt=1 (queue active)
Apr 22 13:52:55 vps04 postfix/smtpd[16215]: disconnect from
unknown[74.51.38.172]
Apr 22 13:52:56 vps04 postfix/local[16220]: B3E982010001:
to=,
orig_to=, relay=local, delay=1.8,
delays=1.1/0/0/0.77, dsn=2.0.0, status=sent (delivered to command:
/usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
   



Apr 22 13:57:10 vps04 dovecot: POP3(rduval.csm-ltd.com): Disconnected:
Logged out top=1/2030, retr=1/14072443, del=1/1, size=14072420
   



Well, dovecot logs that you've actually received a ~14MB message via 
pop3. You can ensure that this is the message you are looking for by 
checking logs for other connections with dovecot right after postfix 
delivered the message to procmail (if there are other pop3 connections 
with your account between 13:52:55 and 13:57:10).You'd also have to 
check previous pop3 connection (one before 13:52:55) and all mails 
received between found pop3 connection and 13:52:55 if there were 
actually any other ~14MB messages delivered for you. Anyways postfix did 
it's job.



Pawel Lesniak