[courier-users] Handling Unknown Addresses
Gordan Bobic
I've been using courier for a while now and I'm generally quite happy with
it. I quite like being able to use just one package, rather than mixing
and matching one SMTP daemon with another IMAP daemon with another POP3
daemon, etc. But one thing really annoys me. It always seems to accept
email, provided it accepts email for that domain - even if the user
doesn't exist, and the email is thus undeliverable. This means my outgoing
spool fills up with spam bounces.
I'm assuming this is due to my having misconfigured it in some way, but
I'm not sure where to look for the problem. How can I ensure that the
undeliverable recipients are identified and the connection dropped as
soon as the RCPT TO: command is received?
Thanks.
Gordan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Lisa Muir
>
> I'm assuming this is due to my having misconfigured it in some way, but
> I'm not sure where to look for the problem. How can I ensure that the
> undeliverable recipients are identified and the connection dropped as
> soon as the RCPT TO: command is received?
sounds like you are using a very old version of courier. Try using an
up to date one.
Lisa.
Gordan Bobic
>> I'm assuming this is due to my having misconfigured it in some way, but
>> I'm not sure where to look for the problem. How can I ensure that the
>> undeliverable recipients are identified and the connection dropped as
>> soon as the RCPT TO: command is received?
>
> sounds like you are using a very old version of courier. Try using an
> up to date one.
Interesting - any info on when this behaviour was changed? I just tested
it on a box running 0.56, and yes, it rejects right after RCPT TO:.
Thanks.
Gordan
Jerry Amundson
>
> >> I'm assuming this is due to my having misconfigured it in some way, but
> >> I'm not sure where to look for the problem. How can I ensure that the
> >> undeliverable recipients are identified and the connection dropped as
> >> soon as the RCPT TO: command is received?
> >
> > sounds like you are using a very old version of courier. Try using an
> > up to date one.
>
> Interesting - any info on when this behaviour was changed? I just tested
> it on a box running 0.56, and yes, it rejects right after RCPT TO:.
I don't recall any version which accepted Anyone@domain by default.
Sounds like you may have a catch-all somewhere. Check .courier files,
etc/courier/alias*, and so on.
jerry
--
"Oh joy! Rapture! I've got a brain"
-Scarecrow
Bernd Wurst
Content-Type: multipart/signed; boundary="nextPart6346405.Sbg9JU0vIi";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
--nextPart6346405.Sbg9JU0vIi
Content-Type: text/plain;
charset="ansi_x3.4-1968"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi.
Am Mittwoch, 10. Oktober 2007 schrieb Gordan Bobic:
> I've been using courier for a while now and I'm generally quite happy with
> it. I quite like being able to use just one package, rather than mixing
> and matching one SMTP daemon with another IMAP daemon with another POP3
> daemon, etc. But one thing really annoys me. It always seems to accept
> email, provided it accepts email for that domain - even if the user
> doesn't exist, and the email is thus undeliverable. This means my outgoing
> spool fills up with spam bounces.
>
> I'm assuming this is due to my having misconfigured it in some way, but
> I'm not sure where to look for the problem. How can I ensure that the
> undeliverable recipients are identified and the connection dropped as
> soon as the RCPT TO: command is received?
Make sure the "mail" useraccount (or whoever the ESMTP-daemon runs as) is a=
ble=20
to see your .courier-files.
Courier checks during the SMTP dialog if your address exists. But if it can=
't=20
read your directory, it will accept everything for that domain.
cu, Bernd
=2D-=20
Und ihr wundert wuch, dass es euch schlecht geht?
- Dirk Bach bei der Echo-Verleihung 2004 zur Musikindustrie
--nextPart6346405.Sbg9JU0vIi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iQIVAwUARwzxuA0b18vi86Q/AQKp6hAAxsp7h+Upt8u75AdRSq85v2OYx4/bO5e1
K0iI+6MezyNQnJn8UNUlTnKW+YanlBdFT91n+aP1ntt9/vGJ4aGf74QMLTPjbInl
l63sItK7c6XWqLjgIOAVbd9P8CGh1lxKn8OH8XUuaSuK5Py9DaOgODU+M9Cg5YPW
3XyQYsaHkgX17XWwRi194RoiPXZi/C+UK3lWlXocWLu3lRDRm4nmeWaAmbBYkUph
vnhKUQiOsntUiIrxEDy2GYbojpfMy8vbTv2zg/KN++8if5KHMudAxiaYS5MGy3ax
Q6H+XG82RXIi2FldXhTn+u1JkX67mnIxBv7M9HXgrGBpFCggetrThVkRBJCDdBRt
hRlkAoZ/XMnhrtUnxf1Cmkkh2cL5V2ShQ/VFUZXKVxyX++4AK8tj00fpRlqrfr+x
veAOZQV2QE9Rj/SnCsEMRDVw+i2iROuKabsU0n8jpQKZabFAwiAic9Abek+tGZYy
2vmITPG3vDPK38tRKa8OxO8Ivqopfc1X9ydYeA3gJV6pmcSuy/oGaPswb7yX0Fpf
ClAHYddXd9+YW4PVxwIphs7YtpmwpJTkom5gk6XpxHdUOuGfDApWht4fHiagU00q
Eskr4hPRH6D1tWnhP+4R1GyPbWp9SRJjmY5/AYQltjrGL92kPnI74tClKSlM/Xpe
lf1JsjTBimM=
=u/j8
-----END PGP SIGNATURE-----
--nextPart6346405.Sbg9JU0vIi--
--===============0651882917==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--===============0651882917==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
--===============0651882917==--
Gordan Bobic
> On 10/10/07, Gordan Bobic <gor...@bobich.net> wrote:
>> On Wed, 10 Oct 2007, Lisa Muir wrote:
>>
>>>> I'm assuming this is due to my having misconfigured it in some way, but
>>>> I'm not sure where to look for the problem. How can I ensure that the
>>>> undeliverable recipients are identified and the connection dropped as
>>>> soon as the RCPT TO: command is received?
>>>
>>> sounds like you are using a very old version of courier. Try using an
>>> up to date one.
>>
>> Interesting - any info on when this behaviour was changed? I just tested
>> it on a box running 0.56, and yes, it rejects right after RCPT TO:.
>
> I don't recall any version which accepted Anyone@domain by default.
> Sounds like you may have a catch-all somewhere. Check .courier files,
> etc/courier/alias*, and so on.
There were aliases, but definitely no catchalls. Otherwise the message
would be deliverable, rather than bounce back. It was version 0.4x that I
was running, but I'm not sure which one exactly. The mail server in
question expired recently, hence why I'm looking into my upgrade options.
But if this is now working I think I'll stick with Courier. :-)
Gordan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Gordan Bobic
>> I've been using courier for a while now and I'm generally quite happy with
>> it. I quite like being able to use just one package, rather than mixing
>> and matching one SMTP daemon with another IMAP daemon with another POP3
>> daemon, etc. But one thing really annoys me. It always seems to accept
>> email, provided it accepts email for that domain - even if the user
>> doesn't exist, and the email is thus undeliverable. This means my outgoing
>> spool fills up with spam bounces.
>>
>> I'm assuming this is due to my having misconfigured it in some way, but
>> I'm not sure where to look for the problem. How can I ensure that the
>> undeliverable recipients are identified and the connection dropped as
>> soon as the RCPT TO: command is received?
>
> Make sure the "mail" useraccount (or whoever the ESMTP-daemon runs as) is able
> to see your .courier-files.
> Courier checks during the SMTP dialog if your address exists. But if it can't
> read your directory, it will accept everything for that domain.
What .courier files? Where? In the home directories? Surely it doesn't
check all .courier files in all home directories every time a mail
arrives.
Johnny C. Lam
> On Wed, 10 Oct 2007, Bernd Wurst wrote:
>
>>> I've been using courier for a while now and I'm generally quite happy with
>>> it. I quite like being able to use just one package, rather than mixing
>>> and matching one SMTP daemon with another IMAP daemon with another POP3
>>> daemon, etc. But one thing really annoys me. It always seems to accept
>>> email, provided it accepts email for that domain - even if the user
>>> doesn't exist, and the email is thus undeliverable. This means my outgoing
>>> spool fills up with spam bounces.
>>>
>>> I'm assuming this is due to my having misconfigured it in some way, but
>>> I'm not sure where to look for the problem. How can I ensure that the
>>> undeliverable recipients are identified and the connection dropped as
>>> soon as the RCPT TO: command is received?
>> Make sure the "mail" useraccount (or whoever the ESMTP-daemon runs as) is able
>> to see your .courier-files.
>> Courier checks during the SMTP dialog if your address exists. But if it can't
>> read your directory, it will accept everything for that domain.
>
> What .courier files? Where? In the home directories? Surely it doesn't
> check all .courier files in all home directories every time a mail
> arrives.
No, Courier doesn't. If a mail is slated for local delivery, then
Courier looks up the system user associated with that email address
(after aliases are expanded) using authdaemon to locate the home
directory for that user. That home directory is searched for .courier
files. You just need to make sure that those .courier files are
readable by that system user.
Cheers,
-- Johnny C. Lam
Gordan Bobic
Yes, but that would imply that Courier has somehow established that it
should be looking up that user's .courier files. I was seeing messages
getting accepted for users that are not aliased. It should have just
flatly rejected them as soon as it saw the address.
Either way, it doesn't matter any more - the fact that the current version
works correctly is good enough for me. :-)
Gordan
Gordon Messmer
> It always seems to accept
> email, provided it accepts email for that domain - even if the user
> doesn't exist, and the email is thus undeliverable. This means my outgoing
> spool fills up with spam bounces.
>
> I'm assuming this is due to my having misconfigured it in some way
Yes, that is likely. However, since you haven't told us how the domain
in question is configured, we can only guess as to what's wrong.
I might venture a guess that you've created a virtual domain alias
(@domain: user), and that user's home directory isn't readable by the
user as which courier runs. In that case, courier can't check for the
dot-courier files in the user's home directory during the SMTP
conversation, and it has to accept everything. You'd need to add read
and execute permissions to the user's home directory to fix that problem.
If that's not it, you need to tell us whether the domain is local or
hosted, how the users are configured, whether or not there are any
.courier-*default files in /etc/courier/aliasdir, and anything else that
might be relevant to the domain's configuration. The version shouldn't
matter; Courier's smtp service has never behaved the way you describe
unless specifically configured to do so.
Gordan Bobic
>> It always seems to accept
>> email, provided it accepts email for that domain - even if the user
>> doesn't exist, and the email is thus undeliverable. This means my outgoing
>> spool fills up with spam bounces.
>>
>> I'm assuming this is due to my having misconfigured it in some way
>
> Yes, that is likely. However, since you haven't told us how the domain
> in question is configured, we can only guess as to what's wrong.
>
> I might venture a guess that you've created a virtual domain alias
> (@domain: user), and that user's home directory isn't readable by the
> user as which courier runs.
There were no virtual domain catchalls. There were some
user@domain: otheruser
aliases, though.
Sadly, as I said, the server this was running on expired, and I hadn't
noticed that the much newer backup server wasn't suffering from the same
unknown address problem. Silly me for not checking first. The config files
were pretty much a straight copy between them, so I think the first
response was probably correct.
> If that's not it, you need to tell us whether the domain is local or
> hosted, how the users are configured, whether or not there are any
> .courier-*default files in /etc/courier/aliasdir, and anything else that
> might be relevant to the domain's configuration. The version shouldn't
> matter; Courier's smtp service has never behaved the way you describe
> unless specifically configured to do so.
Odd. There are no virtual domains on the system per se, and no catchalls.
If there was an obscure mistake in the config that by some miracle didn't
get copied to the backup server, then I guess it went away with the RAID
crash. Oh, well.
Gordan
Sam Varshavchik
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
--===============0032648660==
Content-Type: multipart/signed;
boundary="=_mimegpg-commodore.email-scan.com-15680-1192055517-0001";
micalg=pgp-sha1; protocol="application/pgp-signature"
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
--=_mimegpg-commodore.email-scan.com-15680-1192055517-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Gordan Bobic writes:
>
> Yes, but that would imply that Courier has somehow established that it
> should be looking up that user's .courier files. I was seeing messages
> getting accepted for users that are not aliased. It should have just
> flatly rejected them as soon as it saw the address.
If a message is addressed to user...@example.com, the corresponding
.courier file would be ~user/.courier-foo. If user's home directory cannot
be searched, the server will accept the message, then once delivery
commences the message will get bounced if .courier-foo does not exist.
--=_mimegpg-commodore.email-scan.com-15680-1192055517-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHDVLdx9p3GYHlUOIRAotiAJ9lyfzQACD2LfM+qLJcZllaHsKLiwCcDefl
vBIhabocuzNiJHQLnsJZPfk=
=hvD1
-----END PGP SIGNATURE-----
--=_mimegpg-commodore.email-scan.com-15680-1192055517-0001--
--===============0032648660==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--===============0032648660==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
--===============0032648660==--