Sriram Nyshadham <sriram.nyshadham@...> wrote:

> I am new to postfix and am wondering what is the difference between qstat and
postqueue contents. When I check my qstat
> I get only 4000 mails in the queue. Whereas when I try postqueue, I See around
18000. Please help me.

Stick to postqueue.  Isn't qstat for qmail?

--
Sahil Tandon <sahil@...>

Daryl:
> Greetings,
>             For the second time in a month I have a postfix/sendmail: fatal:
chdir
> /var/spool/postfix Permission denied error.
> There are no possible solutions in my logs, and googling, has found nothing.
My permissions
> for postfix are correct;
>
> #ls -ld /var/spool/postfix
> drwxrwx--- 20 root postfix 4096 2008-11-14 11:57 /var/spool/postfix

Run:
	 postfix set-permissions

to fix this.

	 Wietse

> Running postfix check recently warned me about root not owning certain dir.
which I have
> changed.
>
> I have recently re-configured SAMBA on the same server and until then postfix
was working
> fine. Just curious to know if somebody has had the same problems.
>
> Any help much appreciated!
>
>
>
>
>

Adrian Overbury:
> Is it possible, if I specify a mailbox_command in my main.cf, to pipe
> any output that produces on stdout to somewhere else?  Like, say, to

$ man logger
$ man postlog

	 Wietse

No Sahil,

Qstat is also used for Postfix. I just found that postqueue also displays the
repeated attempts to connect to any mail server(s) which are not accepting
mails. That's why the count becomes bigger. I believe qstat gives the right
value.


Thanks,
Sriram Nyshadham.


-----Original Message-----
From: owner-postfix-users@... [mailto:owner-postfix-users@...]
On Behalf Of Sahil Tandon
Sent: Monday, December 01, 2008 5:12 PM
To: postfix-users@...
Subject: Re: Qstat and Postqueue

Sriram Nyshadham <sriram.nyshadham@...> wrote:

> I am new to postfix and am wondering what is the difference between qstat and
postqueue contents. When I check my qstat
> I get only 4000 mails in the queue. Whereas when I try postqueue, I See around
18000. Please help me.

Stick to postqueue.  Isn't qstat for qmail?

--
Sahil Tandon <sahil@...>
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.12/1821 - Release Date: 11/30/2008 5:53
PM


--------------------------------------------------
Confidentiality And Disclaimer Notice
Please do not print this email unless it is absolutely necessary. The
information contained in this electronic message and any attachments to this
message are intended for the exclusive use of the addressee(s) and may contain
proprietary, confidential or privileged information. If you are not the intended
recipient, you should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately and destroy all copies of this message and any
attachments. WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence of
viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email. ......www.netenrich.com
-------------------------------------------------

Sriram Nyshadham wrote:

[please don't top-post]

> No Sahil,
>
> Qstat is also used for Postfix.

What is Qstat and where did it come from?  All the references
I find on google indicate it's part of qmail.  It's certainly
not part of postfix.  I would always trust an official postfix
utility before a non-postfix utility, and far before some
seldom-used tool.

> I just found that postqueue also displays the repeated attempts to connect to
any mail server(s) which are not accepting mails. That's why the count becomes
bigger.

No, but your "wc -l" command will count blank lines and
multiple recipients.  This will give an inflated view of the
queue, especially if you have some messages with a large
number of recipients.

> I believe qstat gives the right value.

It's possible for both numbers to be right, for some value of
right.  Postqueue is known to be correct and to work as
documented, the jury is still out on Qstat.

--
Noel Jones

mouss ha scritto:
> Simone Felici a écrit :
>> Why? Uhm, dunno...
>> It seems certain mailclients has Autenticated smtp enabled as default
>> and if the client found the smtp server support it, then it try to send
>> in auth. This return an error, due inappropriate settings of the client.
>
> if you know their IPs, you can use  smtpd_discard_ehlo_keyword_address_maps
>


Mouss,
this could be a solution... but haven't find any example or documation to try
it.
Could you pount me at any example?

The initial problem was:
I've an SMTP server for customers, with standard smtp open only from a range of
IPs.
Could I provide normal smtp service for customers of a range of known IP (like
now) and open my server to all the world
for smtp service but ONLY if autenthicated smtp i sused?

Is the MUA with an IP of my customers?
YES: It can send without any authentication.
NO: It can send ONLY it a user/pass is provided.

Simon







--
Simone Felici                    E-Mail: s.felici@...
Divisione Tecnica                Tel:    0461 030 111
Alpikom S.p.A.                   Fax:    0461 030 112
v.Fersina, 23 - 38100 Trento     URL:    http://www.alpikom.it

Hi to all,
i want to set a dimension limit in relation to recipients number and
attachment's size; that is if number_recipients * attachment's size
exceed 100MB than i want to discard these email, otherwise i can permit
them.
Can i do it?
How?
Thanks in advance

For the past couple of weeks we've been getting a lot of spam from valid
mail accounts on our domain. The spam gets automatically white listed
since it's from our domain. Short of removing our own domain from our
white lists, I'm looking for a way to put an end to this. Our server
already requires smtp auth for relaying. Is it possible to apply the
same idea to local accounts trying to deliver mail back to local
accounts? I.E., if the sender claims to be joeuser@... and
wants to email joeuser or janedoe on ourdomain.com, require them to
authenticate with the server first. Most of the spam is being forged as
webmaster or postmaster which are both accounts I need to keep intact.

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = judelawfirm.com, mail1.judelawfirm.com, mail1.jude,
localhost, localhost.localdomain, localhost.judelawfirm.com
mydomain = judelawfirm.com
myhostname = mail1.judelawfirm.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24
myorigin = mail1.judelawfirm.com
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES
sample_directory = /usr/share/doc/postfix-2.4.5/samples
sender_bcc_maps = hash:/etc/aliases_bcc
sender_canonical_classes = header_sender
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname
smtpd_recipient_restrictions = permit_sasl_authenticated
permit_mynetworks       reject_unauth_destination
reject_unlisted_recipient  reject_non_fqdn_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550

Simone Felici a écrit :
> mouss ha scritto:
>> Simone Felici a écrit :
>>> Why? Uhm, dunno...
>>> It seems certain mailclients has Autenticated smtp enabled as default
>>> and if the client found the smtp server support it, then it try to send
>>> in auth. This return an error, due inappropriate settings of the client.
>>
>> if you know their IPs, you can use
>> smtpd_discard_ehlo_keyword_address_maps
>>
>
>
> Mouss,
> this could be a solution... but haven't find any example or documation
> to try it.
> Could you pount me at any example?

make sure to read:

http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps



smtpd_discard_ehlo_keyword_address_maps
	 hash:/etc/postfix/discard_ehlo

== discard_ehlo
10.1.2.3 starttls, auth, silent-discard

(silent-discard prevents postfix from logging this "keyword discard"
action).


>
> The initial problem was:
> I've an SMTP server for customers, with standard smtp open only from a
> range of IPs.
> Could I provide normal smtp service for customers of a range of known IP
> (like now) and open my server to all the world for smtp service but ONLY
> if autenthicated smtp i sused?
>
> Is the MUA with an IP of my customers?
> YES: It can send without any authentication.
> NO: It can send ONLY it a user/pass is provided.
>

Hello,

Spammers often send (forged) mail where "mail from" address is the same as
"rcpt to" address. An extension of that could be using a "mail from"
address where src domain is one of our valid virtual domains. I can only
think of 3 cases:
1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail, installed
on the same MTA host).
2) Authenticated sender -> Legit users authenticated by SASL -> Should pass
3) All the rest -> Should be rejected (SPAM) (assuming a simple single-MTA
config, where MX -receiving mail server- is the same as MTA -outbound
sending mail server-)

Which is the best/preferred Postfix config to filter out that kind of spam?

I have all my valid domains in:
virtual_mailbox_domains     = hash:/etc/postfix/vdomain

The current format of /etc/postfix/vdomain is:
domain1          whatever
domain2          whatever

So perhaps I could do somthing like:
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    XXXXX,
    permit

where XXXX could be some kind of "check_sender_access" clausule, rejecting
domains listed in $virtual_mailbox_domains. How could I implement this? Is
there any other preferred solution?

Another idea could be setting a SPF record for my domains and then some
kind of SPF checks (how could I do that?). I know it is a must but I'd
prefer to leave the SPF setup for the next stage (I'd like to deeply review
all pros/cons, ~all vs ?all, etc).

Cheers,
-Roman

mouss wrote:
> Simone Felici a écrit :
>> mouss ha scritto:
>>> Simone Felici a écrit :
>>>> Why? Uhm, dunno...
>>>> It seems certain mailclients has Autenticated smtp enabled as default
>>>> and if the client found the smtp server support it, then it try to send
>>>> in auth. This return an error, due inappropriate settings of the client.
>>> if you know their IPs, you can use
>>> smtpd_discard_ehlo_keyword_address_maps
>>>
>>
>> Mouss,
>> this could be a solution... but haven't find any example or documation
>> to try it.
>> Could you pount me at any example?
>
> make sure to read:
>
> http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
>
>
>
> smtpd_discard_ehlo_keyword_address_maps
>  hash:/etc/postfix/discard_ehlo
>
> == discard_ehlo
> 10.1.2.3 starttls, auth, silent-discard
>
> (silent-discard prevents postfix from logging this "keyword discard"
> action).
>
>


(discarding starttls may be too much, but OP can decide for
himself)


I think this is even easier:
http://www.postfix.org/postconf.5.html#smtpd_sasl_exceptions_networks

The simplest form of this is:
# main.cf
smtpd_sasl_exceptions_networks = $mynetworks


>> The initial problem was:
>> I've an SMTP server for customers, with standard smtp open only from a
>> range of IPs.
>> Could I provide normal smtp service for customers of a range of known IP
>> (like now) and open my server to all the world for smtp service but ONLY
>> if autenthicated smtp i sused?
>>
>> Is the MUA with an IP of my customers?
>> YES: It can send without any authentication.
>> NO: It can send ONLY it a user/pass is provided.
>>
>

The behavior you describe is the standard settings:

smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    ... other restrictions ...

You only need to make special arrangements such as mouss and I
describe when you don't want to ever offer AUTH to local
clients.  Offering AUTH to everyone does not present a problem
to the vast majority of clients.

--
Noel Jones

Roman Medina-Heigl Hernandez wrote:
> Hello,
>
> Spammers often send (forged) mail where "mail from" address is the same as
> "rcpt to" address. An extension of that could be using a "mail from"
> address where src domain is one of our valid virtual domains. I can only
> think of 3 cases:
> 1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail, installed
> on the same MTA host).
> 2) Authenticated sender -> Legit users authenticated by SASL -> Should pass
> 3) All the rest -> Should be rejected (SPAM) (assuming a simple single-MTA
> config, where MX -receiving mail server- is the same as MTA -outbound
> sending mail server-)
>
> Which is the best/preferred Postfix config to filter out that kind of spam?
>
> I have all my valid domains in:
> virtual_mailbox_domains     = hash:/etc/postfix/vdomain
>
> The current format of /etc/postfix/vdomain is:
> domain1          whatever
> domain2          whatever
>
> So perhaps I could do somthing like:
> smtpd_sender_restrictions =
> smtpd_recipient_restrictions =
>    permit_mynetworks,
>    reject_unauth_destination,
>    XXXXX,
>    permit
>
> where XXXX could be some kind of "check_sender_access" clausule, rejecting
> domains listed in $virtual_mailbox_domains. How could I implement this? Is
> there any other preferred solution?

Yes, you can use a map for this;
      XXXX above =
    check_sender_access hash:/etc/postfix/mydomains

# mydomains
example.com  REJECT inside sender not allowed
example.net  REJECT inside sender not allowed
...

Note this will reject some legit mail.  Spamassassin is
probably a better choice for filtering this type mail.

>
> Another idea could be setting a SPF record for my domains and then some
> kind of SPF checks (how could I do that?). I know it is a must but I'd
> prefer to leave the SPF setup for the next stage (I'd like to deeply review
> all pros/cons, ~all vs ?all, etc).

Yes, SPF will help this, but if you reject mail that fails SPF
checks you will have the same false positives as the above
solution.
Adding SPF to your domain is simply publishing a couple extra
DNS records, very simple to add.
http://www.openspf.org/

Checking SPF records in postfix requires a policy service.
There are several for postfix listed under
http://www.openspf.org/Implementations#mta-extensions

Also, if you have a recent version of postfix you can use any
milter that supports SPF.  Many of them have additional features.


--
Noel Jones

Quick question--

Nov 30 17:39:03 p34 postfix/smtpd[15257]: 6B3A310676:
client=localhost.localdomain[127.0.0.1]
Nov 30 17:39:03 p34 postfix/cleanup[15260]: 6B3A310676:
message-id=<20081130223903.6B3A310676@...>
Nov 30 17:39:03 p34 postfix/qmgr[18872]: 6B3A310676:
from=<root@...>, size=430, nrcpt=1 (queue active)
Nov 30 17:39:03 p34 postfix/smtpd[15257]: lost connection after QUIT from
localhost.localdomain[127.0.0.1]
Nov 30 17:39:03 p34 postfix/smtpd[15257]: disconnect from
localhost.localdomain[127.0.0.1]

Why would it lose the connection from localhost when sending a test message
from the 3dm2 web interface?  Should I escalate this to 3ware support/or
is there a parameter I can change to fix this/what is causing this?

Justin.

Noel Jones a écrit :
> mouss wrote:
>> Simone Felici a écrit :
>>> mouss ha scritto:
>>>> Simone Felici a écrit :
>>>>> Why? Uhm, dunno...
>>>>> It seems certain mailclients has Autenticated smtp enabled as default
>>>>> and if the client found the smtp server support it, then it try to
>>>>> send
>>>>> in auth. This return an error, due inappropriate settings of the
>>>>> client.
>>>> if you know their IPs, you can use
>>>> smtpd_discard_ehlo_keyword_address_maps
>>>>
>>>
>>> Mouss,
>>> this could be a solution... but haven't find any example or documation
>>> to try it.
>>> Could you pount me at any example?
>>
>> make sure to read:
>>
>>
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
>>
>>
>>
>>
>> smtpd_discard_ehlo_keyword_address_maps
>>     hash:/etc/postfix/discard_ehlo
>>
>> == discard_ehlo
>> 10.1.2.3    starttls, auth, silent-discard
>>
>> (silent-discard prevents postfix from logging this "keyword discard"
>> action).
>>
>>
>
>
> (discarding starttls may be too much, but OP can decide for himself)
>

yes. I only cited it to show that multiple keywords can be discarded.

>
> I think this is even easier:
> http://www.postfix.org/postconf.5.html#smtpd_sasl_exceptions_networks
>
> The simplest form of this is:
> # main.cf
> smtpd_sasl_exceptions_networks = $mynetworks
>
>
>>> The initial problem was:
>>> I've an SMTP server for customers, with standard smtp open only from a
>>> range of IPs.
>>> Could I provide normal smtp service for customers of a range of known IP
>>> (like now) and open my server to all the world for smtp service but ONLY
>>> if autenthicated smtp i sused?
>>>
>>> Is the MUA with an IP of my customers?
>>> YES: It can send without any authentication.
>>> NO: It can send ONLY it a user/pass is provided.
>>>
>>
>
> The behavior you describe is the standard settings:
>
> smtpd_recipient_restrictions =
>   permit_mynetworks
>   permit_sasl_authenticated
>   reject_unauth_destination
>   ... other restrictions ...
>
> You only need to make special arrangements such as mouss and I describe
> when you don't want to ever offer AUTH to local clients.  Offering AUTH
> to everyone does not present a problem to the vast majority of clients.
>

It's unclear whether he actually found misbehaving MUAs or if he is just
  fearing the unknown ;-p

J.P. Trosclair wrote:
> For the past couple of weeks we've been getting a lot of spam from valid
> mail accounts on our domain. The spam gets automatically white listed
> since it's from our domain. Short of removing our own domain from our
> white lists, I'm looking for a way to put an end to this. Our server
> already requires smtp auth for relaying. Is it possible to apply the
> same idea to local accounts trying to deliver mail back to local
> accounts? I.E., if the sender claims to be joeuser@... and
> wants to email joeuser or janedoe on ourdomain.com, require them to
> authenticate with the server first. Most of the spam is being forged as
> webmaster or postmaster which are both accounts I need to keep intact.

Yes, you can reject mail to local domains from
outside/unauthenticated clients.  Note some legit mail arrives
this way, so be prepared for some false positives.

# main.cf
smtpd_recipient_restrictions =
     permit_sasl_authenticated
     permit_mynetworks
     reject_unauth_destination
     reject_unlisted_recipient
# add this here:
     check_sender_access hash:/etc/postfix/mydomains
# consider adding:
     reject_unlisted_sender
     reject_rbl_client zen.spamhaus.org

# mydomains
example.org  REJECT sender not allowed
...other local domains...  REJECT your message here


--
Noel Jones

>
> postconf -n:
>
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> broken_sasl_auth_clients = yes
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> disable_vrfy_command = yes
> html_directory = no
> inet_interfaces = all
> mail_owner = postfix
> mailbox_size_limit = 0
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydestination = judelawfirm.com, mail1.judelawfirm.com, mail1.jude,
> localhost, localhost.localdomain, localhost.judelawfirm.com
> mydomain = judelawfirm.com
> myhostname = mail1.judelawfirm.com
> mynetworks = 127.0.0.0/8, 192.168.1.0/24
> myorigin = mail1.judelawfirm.com
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES
> sample_directory = /usr/share/doc/postfix-2.4.5/samples
> sender_bcc_maps = hash:/etc/aliases_bcc
> sender_canonical_classes = header_sender
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_tls_note_starttls_offer = yes
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP
> smtpd_data_restrictions = reject_unauth_pipelining
> smtpd_helo_required = yes
> smtpd_helo_restrictions = reject_invalid_hostname
> smtpd_recipient_restrictions = permit_sasl_authenticated
> permit_mynetworks       reject_unauth_destination
> reject_unlisted_recipient  reject_non_fqdn_recipient
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain =
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_restrictions = reject_non_fqdn_sender
> reject_unknown_sender_domain
> smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
> smtpd_tls_auth_only = no
> smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
> smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> tls_random_source = dev:/dev/urandom
> unknown_local_recipient_reject_code = 550

Noel Jones escribió:
> Roman Medina-Heigl Hernandez wrote:
>> Hello,
>>
>> Spammers often send (forged) mail where "mail from" address is the
>> same as
>> "rcpt to" address. An extension of that could be using a "mail from"
>> address where src domain is one of our valid virtual domains. I can only
>> think of 3 cases:
>> 1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail,
>> installed
>> on the same MTA host).
>> 2) Authenticated sender -> Legit users authenticated by SASL -> Should
>> pass
>> 3) All the rest -> Should be rejected (SPAM) (assuming a simple
>> single-MTA
>> config, where MX -receiving mail server- is the same as MTA -outbound
>> sending mail server-)
>>
>> Which is the best/preferred Postfix config to filter out that kind of
>> spam?
>>
>> I have all my valid domains in:
>> virtual_mailbox_domains     = hash:/etc/postfix/vdomain
>>
>> The current format of /etc/postfix/vdomain is:
>> domain1          whatever
>> domain2          whatever
>>
>> So perhaps I could do somthing like:
>> smtpd_sender_restrictions =
>> smtpd_recipient_restrictions =
>>    permit_mynetworks,
>>    reject_unauth_destination,
>>    XXXXX,
>>    permit
>>
>> where XXXX could be some kind of "check_sender_access" clausule,
>> rejecting
>> domains listed in $virtual_mailbox_domains. How could I implement
>> this? Is
>> there any other preferred solution?
>
> Yes, you can use a map for this;
>     XXXX above =
>   check_sender_access hash:/etc/postfix/mydomains
>
> # mydomains
> example.com  REJECT inside sender not allowed
> example.net  REJECT inside sender not allowed
> ...

So there is no other way to do this without having to "duplicate" the
same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I
thought perhaps it could exist some directive of the form:
reject_mydestination_domain_sender or something similar to avoid
duplicating domain databases ;-)).

> Note this will reject some legit mail.  Spamassassin is probably a

Could you elaborate on that legit mail cases? Examples? It's very important
for me and I couldn't figure any legit cases (apart from the ones I already
mentioned).

> better choice for filtering this type mail.

If I use spamassasing for this, I have to supply my vdomains to
spamassassin. Currently, I implemented a quick have in Amavis, so all
domains are treated as local:
@local_domains_acl = qw( . );
My Amavis/spamassasing setup is not filtering at all; it is only used for
marking/scoring (adding headers to) mails (filtering is performed via
Sieve, based on X-Spam-*/X-Amavis-* Headers).

> http://www.openspf.org/

As I said, SPF is plannified for next stage, and I'll have a look to
different resources (thanks for your notes!!).

Regards,
-Roman

Roman Medina-Heigl Hernandez wrote:
> Noel Jones escribió:
>> Roman Medina-Heigl Hernandez wrote:
>>> Hello,
>>>
>>> Spammers often send (forged) mail where "mail from" address is the
>>> same as
>>> "rcpt to" address. An extension of that could be using a "mail from"
>>> address where src domain is one of our valid virtual domains. I can only
>>> think of 3 cases:
>>> 1) Src IP is 127.0.0.1 -> Mail should pass (eg: sent by webmail,
>>> installed
>>> on the same MTA host).
>>> 2) Authenticated sender -> Legit users authenticated by SASL -> Should
>>> pass
>>> 3) All the rest -> Should be rejected (SPAM) (assuming a simple
>>> single-MTA
>>> config, where MX -receiving mail server- is the same as MTA -outbound
>>> sending mail server-)
>>>
>>> Which is the best/preferred Postfix config to filter out that kind of
>>> spam?
>>>
>>> I have all my valid domains in:
>>> virtual_mailbox_domains     = hash:/etc/postfix/vdomain
>>>
>>> The current format of /etc/postfix/vdomain is:
>>> domain1          whatever
>>> domain2          whatever
>>>
>>> So perhaps I could do somthing like:
>>> smtpd_sender_restrictions =
>>> smtpd_recipient_restrictions =
>>>    permit_mynetworks,
>>>    reject_unauth_destination,
>>>    XXXXX,
>>>    permit
>>>
>>> where XXXX could be some kind of "check_sender_access" clausule,
>>> rejecting
>>> domains listed in $virtual_mailbox_domains. How could I implement
>>> this? Is
>>> there any other preferred solution?
>> Yes, you can use a map for this;
>>     XXXX above =
>>   check_sender_access hash:/etc/postfix/mydomains
>>
>> # mydomains
>> example.com  REJECT inside sender not allowed
>> example.net  REJECT inside sender not allowed
>> ...
>
> So there is no other way to do this without having to "duplicate" the
> same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I
> thought perhaps it could exist some directive of the form:
> reject_mydestination_domain_sender or something similar to avoid
> duplicating domain databases ;-)).

If you have a large number of domains, keep a separate list of
the domains and let the computer build the different tables
for you.  Use a Makefile to make it easy.


>
>> Note this will reject some legit mail.  Spamassassin is probably a
>
> Could you elaborate on that legit mail cases? Examples? It's very important
> for me and I couldn't figure any legit cases (apart from the ones I already
> mentioned).

Some web invites / rotten mail lists / web notifications etc.
will arrive with the recipient's address as the sender.  While
this is generally poor form, a few legit sites do it.  I don't
have any specific examples, but know they exist.  "trust me"

--
Noel Jones

On Mon, Dec 01, 2008 at 11:05:44AM -0500, Justin Piszcz wrote:

> Quick question--
>
> Nov 30 17:39:03 p34 postfix/smtpd[15257]: 6B3A310676:
> client=localhost.localdomain[127.0.0.1]
> Nov 30 17:39:03 p34 postfix/cleanup[15260]: 6B3A310676:
> message-id=<20081130223903.6B3A310676@...>
> Nov 30 17:39:03 p34 postfix/qmgr[18872]: 6B3A310676:
> from=<root@...>, size=430, nrcpt=1 (queue active)
> Nov 30 17:39:03 p34 postfix/smtpd[15257]: lost connection after QUIT from
> localhost.localdomain[127.0.0.1]
> Nov 30 17:39:03 p34 postfix/smtpd[15257]: disconnect from
> localhost.localdomain[127.0.0.1]
>
> Why would it lose the connection from localhost when sending a test message
> from the 3dm2 web interface?  Should I escalate this to 3ware support/or
> is there a parameter I can change to fix this/what is causing this?

Harmless noise, the client dropped the connection after sending "QUIT" and
the server "221" response could not be sent down an already closed socket.

This is a race. For clients with high enough network latency, the server
sends 221 before the TCP 3-way close handshake completes. For clients
that are close-by (e.g. localhost), the server can "lose" the race, and
find the socket already closed. Use of milters to inspect the QUIT command
can slow down the server further and make this more likely.

There is nothing wrong with lost connections after QUIT. Newer versions
of Postfix only log "lost connection" in the SMTP server during data
transfer or when sending the "." response. The client is free to
disconnect without "QUIT" at all other SMTP protocol stages.

Sufficiently new Postfix releases will not log this condition.

--
	 Viktor.

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

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

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

On 12/1/2008 11:54 AM, Victor Duchovni wrote:
> There is nothing wrong with lost connections after QUIT. Newer versions
> of Postfix only log "lost connection" in the SMTP server during data
> transfer or when sending the "." response. The client is free to
> disconnect without "QUIT" at all other SMTP protocol stages.
>
> Sufficiently new Postfix releases will not log this condition.

Hmmm...

I'm running 2.5.5, and get this almost every time (maybe every time)
when people send through the webmail interface...

It is an older version of squirrelmail (1.4.6)... maybe time to upgrade?

--

Best regards,

Charles

Noel Jones ha scritto:
> mouss wrote:

>>> Mouss,
>>> this could be a solution... but haven't find any example or documation
>>> to try it.
>>> Could you pount me at any example?
>>
>> make sure to read:
>>
>>
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
>>
>>
>>
>>
>> smtpd_discard_ehlo_keyword_address_maps
>>     hash:/etc/postfix/discard_ehlo
>>
>> == discard_ehlo
>> 10.1.2.3    starttls, auth, silent-discard
>>
>> (silent-discard prevents postfix from logging this "keyword discard"
>> action).
>>
>>

Both are good solutions, I'll try these!

Thank's a lot!!!

Simon

On Mon, Dec 01, 2008 at 11:58:42AM -0500, Charles Marcus wrote:

> On 12/1/2008 11:54 AM, Victor Duchovni wrote:
> > There is nothing wrong with lost connections after QUIT. Newer versions
> > of Postfix only log "lost connection" in the SMTP server during data
> > transfer or when sending the "." response. The client is free to
> > disconnect without "QUIT" at all other SMTP protocol stages.
> >
> > Sufficiently new Postfix releases will not log this condition.
>
> Hmmm...
>
> I'm running 2.5.5, and get this almost every time (maybe every time)
> when people send through the webmail interface...
>

Sorry, Postfix won't log clients disconnecting without sending QUIT,
but it will log failure to send "221 ...".

The reason is that with PIPELINEd ESMTP, the "250 ..." response to
"." and "221" response to QUIT are often sent in the same I/O operation,
so it is appropriate to report I/O errors when sending QUIT, at least
when there are previous responses in the output buffer.  Postfix 2.3+
complains about problems flushing QUIT unconditionally.

     quit_cmd(SMTPD_STATE *state, int unused_argc, SMTPD_TOKEN *unused_argv)
     {

	 /*
	  * Don't bother checking the syntax.
	  */
	 smtpd_chat_reply(state, "221 2.0.0 Bye");

	 /*
	  * When the "." and quit replies are pipelined, make sure they are
	  * flushed now, to avoid repeated mail deliveries in case of a crash in
	  * the "clean up before disconnect" code.
	  *
	  * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
	  * of Postfix 2.3 we use smtp_flush() for better error reporting.
	  */
	 smtp_flush(state->client);
	 return (0);
     }

perhaps the flush should be suppressed if there was no pending unwritten
data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.

--
	 Viktor.

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

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

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

Noel Jones escribió:

> If you have a large number of domains, keep a separate list of the domains and
let the computer build the different tables for you.  Use a Makefile to make it
easy.

Or I could use two different mysql queries, over the same table containing
the vdomains...

> Some web invites / rotten mail lists / web notifications etc. will
> arrive with the recipient's address as the sender.  While this is
> generally poor form, a few legit sites do it.  I don't have any specific
> examples, but know they exist.  "trust me"

Yes, you're right (I trust you! :-)). I did a quick search in my inbox and
found an example: notices from Ubuntu bug tracking system ("Launchpad" at
canonical.com) use that (poor) technique. But I'm wondering:
1) How often could you find this "nasty errors" (yes, difficult question;
impossible to answer, I'd add)
2) How important are this kind of "notices"...

Although it's a personal opinion, it seems that I can afford "loosing" such
mails... On the other hand, perhaps they're identifiable by other means, I
mean, headers, such as:

Return-Path: <bounces@...>
X-Original-To: roman@...
Delivered-To: roman@...
...
Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
	 by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
	 for <roman@...>; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
From: RoMaNSoFt <roman@...>
Reply-To: Bug 26119 <26119@...>
Sender: bounces@...
X-Launchpad-Bug: distribution=ubuntu; sourcepackage=linux-source-2.6.15;
	 component=main; status=Needs Info; importance=Medium;
	 assignee=ben.collins@...;
To: roman@...
Errors-To: bounces@...
X-Generated-By: Launchpad (canonical.com)

Perhaps the "reply-to" header could be an indication of this kind of notices?

You are (again) right, perhaps spamassasin is better for performing this
kind of check... with the added bonus that filtered mail is not dropped,
but quarantined (so you could always rescue a false negative). Do you know
"how well" does it (SA) perform at blocking this spam case (src dom=dst
dom) while recognizing "legit" (but nasty) notices?

For the very same reason, isn't it better to let Spamassassin make
"intelligent" SPF-checks instead of using some other policy server with
Postfix?

Thank you for your responses.

--

Saludos,
-Roman

PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]

Roman Medina-Heigl Hernandez wrote:
> Noel Jones escribió:

> You are (again) right, perhaps spamassasin is better for performing this
> kind of check... with the added bonus that filtered mail is not dropped,
> but quarantined (so you could always rescue a false negative). Do you know
> "how well" does it (SA) perform at blocking this spam case (src dom=dst
> dom) while recognizing "legit" (but nasty) notices?
>
> For the very same reason, isn't it better to let Spamassassin make
> "intelligent" SPF-checks instead of using some other policy server with
> Postfix?

The whole idea of SpamAssassin scoring is that the spamminess
of of messages comes from lots of little things - some
positive scores, some negative scores - that usually adds up
to something that accurately represents whether a message is
spam or not.  No one rule (unless it's a rare 100% guaranteed
spam indicator) ever decides on its own that a message is spam.

While a message might exhibit the From=To and SPF errors
described above, most legit mail still wouldn't trigger enough
points to get into the "likely spam" range.

SpamAssassin itself isn't 100% accurate, but it does fairly
well with a very wide range of junk.  It's a good tool to use,
but you need more than one tool.
Selective RBLs (zen.spamhaus.org is highly recommended),
ClamAV with the Sanesecurity add-on signatures, and careful
postfix checks can reject a lot of spam  before SpamAssassin
ever sees it.

It's also important to note that the settings you use depend
on your user base and your goals - there is no
one-size-fits-all solution, which is why you'll never see such
a thing posted here.  Your best bet is to lurk on the list for
a while or browse the archives to learn what might work well
in your situation.

--
Noel Jones

Dear list,

It's been a hectic couple of weeks, and I'm getting complaints from
users after having upgraded to a new system that mails are coming in
which have been spoofed. I see exactly what's going on - a rogue
system opens up port 25 on my system, tells it the mail's from one of
the users on the system, and then sends the mail to the same user,
completely bypassing my content-filter (amavis) as it's not checked
against the sender or recipient restrictions, somehow.

However, in one of those "crap, what do I do now" moments, I'm
confuzzled as to how to get Postfix to realise that the mail *should*
be checked, since it's coming in from outside the network.

My postconf -n is as follows:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
delay_warning_time = 4h
fallback_transport = virtual
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
inet_interfaces = all
mailbox_command = /usr/bin/maildrop
mailbox_size_limit = 0
mime_header_checks = regexp:/etc/postfix/mime_checks
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = mail.rmacd.com
mynetworks = 127.0.0.0/8
myorigin = /etc/mailname
notify_classes = resource, software, delay
recipient_delimiter = +
relay_domains = proxy:mysql:/etc/postfix/mysql_relay_domains_maps.cf,
lists.rmacd.com
relayhost =
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions =
smtpd_delay_reject = yes
smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,  reject_invalid_hostname,  permit
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination,      permit_mynetworks,
reject_invalid_hostname,        reject_unknown_sender_domain
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions =
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 450
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:1002
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_limit = 104857600
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 1000
virtual_transport = virtual
virtual_uid_maps = static:1002

Any ideas as to what might be the best way to fix this?

Kind regards,
Ronald.

--
Ronald MacDonald
http://www.rmacd.com/

Victor Duchovni:
> On Mon, Dec 01, 2008 at 11:58:42AM -0500, Charles Marcus wrote:
>
> > On 12/1/2008 11:54 AM, Victor Duchovni wrote:
> > > There is nothing wrong with lost connections after QUIT. Newer versions
> > > of Postfix only log "lost connection" in the SMTP server during data
> > > transfer or when sending the "." response. The client is free to
> > > disconnect without "QUIT" at all other SMTP protocol stages.
> > >
> > > Sufficiently new Postfix releases will not log this condition.
> >
> > Hmmm...
> >
> > I'm running 2.5.5, and get this almost every time (maybe every time)
> > when people send through the webmail interface...
> >
>
> Sorry, Postfix won't log clients disconnecting without sending QUIT,
> but it will log failure to send "221 ...".
>
> The reason is that with PIPELINEd ESMTP, the "250 ..." response to
> "." and "221" response to QUIT are often sent in the same I/O operation,
> so it is appropriate to report I/O errors when sending QUIT, at least
> when there are previous responses in the output buffer.  Postfix 2.3+
> complains about problems flushing QUIT unconditionally.
>
>     quit_cmd(SMTPD_STATE *state, int unused_argc, SMTPD_TOKEN *unused_argv)
>     {
>
>  /*
> 	 * Don't bother checking the syntax.
> 	 */
>  smtpd_chat_reply(state, "221 2.0.0 Bye");
>
>  /*
> 	 * When the "." and quit replies are pipelined, make sure they are
> 	 * flushed now, to avoid repeated mail deliveries in case of a crash in
> 	 * the "clean up before disconnect" code.
> 	 *
> 	 * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
> 	 * of Postfix 2.3 we use smtp_flush() for better error reporting.
> 	 */
>  smtp_flush(state->client);
>  return (0);
>     }
>
> perhaps the flush should be suppressed if there was no pending unwritten
> data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.

Postfix has a vstream_peek() function to count the amount of buffered
input, but there is as of yet no API to count the amount of buffered
output.

I am not sure it is safe to overload vstream_peek() for this purpose,
because that would break with full-duplex VSTREAMs when the last
operation on the VSTREAM was a write.

	 Wietse

On Mon, Dec 01, 2008 at 03:25:00PM -0500, Wietse Venema wrote:

> >  /*
> > 	 * Don't bother checking the syntax.
> > 	 */
> >  smtpd_chat_reply(state, "221 2.0.0 Bye");
> >
> >  /*
> > 	 * When the "." and quit replies are pipelined, make sure they are
> > 	 * flushed now, to avoid repeated mail deliveries in case of a crash in
> > 	 * the "clean up before disconnect" code.
> > 	 *
> > 	 * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
> > 	 * of Postfix 2.3 we use smtp_flush() for better error reporting.
> > 	 */
> >  smtp_flush(state->client);
> >
> > perhaps the flush should be suppressed if there was no pending unwritten
> > data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.
>
> Postfix has a vstream_peek() function to count the amount of buffered
> input, but there is as of yet no API to count the amount of buffered
> output.
>
> I am not sure it is safe to overload vstream_peek() for this purpose,
> because that would break with full-duplex VSTREAMs when the last
> operation on the VSTREAM was a write.

I agree that it is not safe to overload vstream_peek(), we need a new
vstream feature to make this possible. Perhaps:

     /*
      * Number of unwritten application data bytes held in a vstream
      * buffer. Note, these may translate a diffent number of bytes
      * ultimately written to the network or a file, if the physical
      * I/O involves encryption, compression or other transformations.
      */
     int vstream_unwritten(VSTREAM *);

--
	 Viktor.

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

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@...?body=unsubscribe%20postfix-users>

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

Ronald MacDonald wrote:
> It's been a hectic couple of weeks, and I'm getting complaints from
> users after having upgraded to a new system that mails are coming in
> which have been spoofed. I see exactly what's going on - a rogue
> system opens up port 25 on my system, tells it the mail's from one of
> the users on the system, and then sends the mail to the same user,
> completely bypassing my content-filter (amavis) as it's not checked
> against the sender or recipient restrictions, somehow.
>
> However, in one of those "crap, what do I do now" moments, I'm
> confuzzled as to how to get Postfix to realise that the mail *should*
> be checked, since it's coming in from outside the network.
>
> Any ideas as to what might be the best way to fix this?

Thank you for the postconf -n output.  Please also provide logs of such
email bypassing your content filter.  We can't help you trace the email
and find the configuration error without them.

On 01/12/2008, postfix@... <postfix@...> wrote:
> Ronald MacDonald wrote:
...
> > However, in one of those "crap, what do I do now" moments, I'm
> > confuzzled as to how to get Postfix to realise that the mail *should*
> > be checked, since it's coming in from outside the network.
> >
> > Any ideas as to what might be the best way to fix this?
> >
>
>  Thank you for the postconf -n output.  Please also provide logs of such
> email bypassing your content filter.  We can't help you trace the email and
> find the configuration error without them.

Of course! I'm sorry.

Here's the mail.log entry
Nov 30 10:51:07 de003221 postfix-policyd: rcpt=91039,
throttle=clear(a), host=83.7.120.131, from=ronald@...,
to=ronald@..., size=1668/10240000, quota=1668/250000000,
  count=1/512(136), rcpt=1/3600(136), threshold=0%|0%|0%
Nov 30 10:51:07 de003221 postfix/cleanup[29357]: 77B106C1F5:
message-id=<20081130105106.77B106C1F5@...>
Nov 30 10:51:07 de003221 postfix/qmgr[14572]: 77B106C1F5:
from=<ronald@...>, size=1995, nrcpt=1 (queue active)
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) ESMTP::10024
/var/lib/amavis/amavis-20081130T103252-28871: <ronald@...> ->
<ronald@...> Received: SIZE=1995 from m
ail.rmacd.com ([127.0.0.1]) by localhost ( [127.0.0.1]) (amavisd-maia,
port 10024) with ESMTP id 28871-10 for <ronald@...>; Sun, 30 Nov
2008 10:51:07 +0000 (GMT)
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) Checking:
[83.7.120.131] <ronald@...> -> <ronald@...>
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) Maia: [check_mail]
WARNING: Size limit (104857600) > max_allowed_packet (16776192);
effective size limit is 16775168 bytes
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) p001 1
Content-Type: text/html, size: 1472 B, name:
Nov 30 10:51:07 de003221 postfix/smtpd[29247]: disconnect from
abie131.neoplus.adsl.tpnet.pl[83.7.120.131]
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) wbl: whitelisted
sender <ronald@...>
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) FWD via SMTP:
[127.0.0.1]:10025 <ronald@...> -> <ronald@...>
Nov 30 10:51:07 de003221 postfix/smtpd[29382]: connect from localhost[127.0.0.1]
Nov 30 10:51:07 de003221 postfix/smtpd[29382]: D27FB6B6AD:
client=localhost[127.0.0.1]
Nov 30 10:51:07 de003221 postfix/cleanup[29365]: D27FB6B6AD:
message-id=<20081130105106.77B106C1F5@...>
Nov 30 10:51:07 de003221 postfix/qmgr[14572]: D27FB6B6AD:
from=<ronald@...>, size=2411, nrcpt=1 (queue active)
Nov 30 10:51:07 de003221 amavis[28871]: (28871-10) Passed CLEAN,
[83.7.120.131] [83.7.120.131] <ronald@...> ->
<ronald@...>, Message-ID: <20081130105106.77B106C1F5@m
ail.rmacd.com>, Hits: -, 718 ms
Nov 30 10:51:07 de003221 postfix/smtpd[29382]: disconnect from
localhost[127.0.0.1]
Nov 30 10:51:08 de003221 authdaemond: received userid lookup request:
ronald@...
Nov 30 10:51:08 de003221 authdaemond: authmysql: trying this module
Nov 30 10:51:08 de003221 authdaemond: SQL query: [SQL QUERY]
Nov 30 10:51:08 de003221 authdaemond: Authenticated
Nov 30 10:51:08 de003221 amavis[28871]: (28871-10) TIMING [total 762
ms] - SMTP EHLO: 5 (1%), SMTP pre-MAIL: 2 (0%), lookup_sql: 5 (1%),
SMTP pre-DATA-flush: 3 (0%), SMTP DATA: 33 (4%), body_hash: 1 (0%), ma
ia_connect: 35 (5%), maia_read_system_config: 1 (0%),
maia_get_mysql_size_limit: 1 (0%), lookup_sql: 4 (1%), mime_decode: 13
(2%), get-file-type1: 237 (31%), parts_decode: 0 (0%), AV-scan-1: 14
(2%), spam-wb
-list: 30 (4%), update_cache: 1 (0%), maia_autocreate_users: 3 (0%),
maia_store_mail: 48 (6%), maia_set_mail_status: 48 (6%),
deal_with_mail_size: 1 (0%), maia_record_tests: 3 (0%),
maia_set_mail_status: 6 (
1%), fwd-connect: 87 (11%), fwd-mail-from: 5 (1%), fwd-rcpt-to: 4
(1%), write-header: 5 (1%), fwd-data: 1 (0%), fwd-data-end: 97 (13%),
fwd-rundown: 1 (0%), main_log_entry: 26 (3%), update_snmp: 3 (0%),
maia
_delete_mail: 35 (5%), maia_cleanup: 0 (0%), maia_disconnect: 0 (0%),
unlink-1-files: 2 (0%), rundown: 1 (0%)
Nov 30 10:51:08 de003221 amavis[28871]: (28871-10) Requesting process
rundown after 10 tasks (and 10 sessions)
Nov 30 10:51:08 de003221 postfix/smtp[29358]: 77B106C1F5:
to=<ronald@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9,
delays=1.2/0/0.01/0.76, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=2
8871-10, from MTA: 250 2.0.0 Ok: queued as D27FB6B6AD)
Nov 30 10:51:08 de003221 postfix/qmgr[14572]: 77B106C1F5: removed
Nov 30 10:51:08 de003221 amavis[28871]: (28871-10) extra modules
loaded: Mail/SpamAssassin/Locales.pm,
Mail/SpamAssassin/Plugin/Bayes.pm,
Mail/SpamAssassin/Plugin/BodyEval.pm, Mail/SpamAssassin/Plugin/Check.
pm, Mail/SpamAssassin/Plugin/DNSEval.pm,
Mail/SpamAssassin/Plugin/HTMLEval.pm,
Mail/SpamAssassin/Plugin/HTTPSMismatch.pm,
Mail/SpamAssassin/Plugin/HeaderEval.pm,
Mail/SpamAssassin/Plugin/ImageInfo.pm, Mail/S
pamAssassin/Plugin/MIMEEval.pm, Mail/SpamAssassin/Plugin/RelayEval.pm,
Mail/SpamAssassin/Plugin/URIDetail.pm,
Mail/SpamAssassin/Plugin/URIEval.pm,
Mail/SpamAssassin/Plugin/VBounce.pm, Mail/SpamAssassin/Plugi
n/WLBLEval.pm
Nov 30 10:51:08 de003221 postfix/pipe[29383]: D27FB6B6AD:
to=<ronald@...>, relay=maildrop, delay=0.59,
delays=0.09/0.05/0/0.45, dsn=2.0.0, status=sent (delivered via
maildrop service)
Nov 30 10:51:08 de003221 postfix/qmgr[14572]: D27FB6B6AD: removed


And the corresponding mail headers.
Return-Path: <ronald@...>
Delivered-To: ronald@...
Received: from localhost (localhost [127.0.0.1])
         by mail.rmacd.com (Postfix) with ESMTP id D27FB6B6AD
         for <ronald@...>; Sun, 30 Nov 2008 10:51:07 +0000 (GMT)
Received: from mail.rmacd.com ([127.0.0.1])
  by localhost ( [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28871-10
  for <ronald@...>; Sun, 30 Nov 2008 10:51:07 +0000 (GMT)
Received: from abie131.neoplus.adsl.tpnet.pl
(abie131.neoplus.adsl.tpnet.pl [83.7.120.131])
         by mail.rmacd.com (Postfix) with SMTP id 77B106C1F5
         for <ronald@...>; Sun, 30 Nov 2008 10:51:06 +0000 (GMT)
To: <ronald@...>
Subject: Weiner to explode now!
From: <ronald@...>
MIME-Version: 1.0
Importance: High
Content-Type: text/html
Message-Id: <20081130105106.77B106C1F5@...>
Date: Sun, 30 Nov 2008 10:51:06 +0000 (GMT)
X-Virus-Scanned: RMacD.com

Hmm!

--Ronald.

--
Ronald MacDonald
http://www.rmacd.com/
0777 235 1655

On 01/12/2008, Ronald MacDonald <ronald@...> wrote:
> On 01/12/2008, postfix@... <postfix@...> wrote:
>  > Ronald MacDonald wrote:
>  ...
>
> > > However, in one of those "crap, what do I do now" moments, I'm
>  > > confuzzled as to how to get Postfix to realise that the mail *should*
>  > > be checked, since it's coming in from outside the network.
>  > >
>  > > Any ideas as to what might be the best way to fix this?
>  > >
>  >
>  >  Thank you for the postconf -n output.  Please also provide logs of such
>  > email bypassing your content filter.  We can't help you trace the email and
>  > find the configuration error without them.
>
>
> Of course! I'm sorry.
>
<cut>

Ah, umm, my bad. Having noticed that magic word "whitelist" in the
logs, after posting to here, I noticed the user had added themselves
to their white list.

And you wonder why they then complain about spam "from themselves"?

Hhmph.

Regards,
Ronald.

[--for the record, I did a find+replace on the logs to anon the user :) heh ]

--
Ronald MacDonald
http://www.rmacd.com/
0777 235 1655