Re: [vchkpw] SMTP Authenticated user is able to anyone in rcpthos ts

[Erwin Hoffmann]

Hi,

At 09:46 11.06.04 +0530, you wrote:
>At 10/06/04 19:11 (), you wrote:
>
>>On Wed, 2004-06-09 at 00:13, Devendra Singh wrote:
>> > At 08/06/04 11:41 (), Tom Collins wrote:
>> > >On Jun 7, 2004, at 9:28 PM, Devendra Singh wrote:
>> > >>I would like to re-frame my Subject: "SMTP Authenticated user is
>> > able to
>> > >>impersonate anyone in rcpthosts".
>> > >
>> > >You could re-frame it even more.  Authenticated SMTP users can use
>> > any
>> > >FROM address and submit mail for any host.
>> > >
>> > >Some clients may have multiple from addresses going through a single
>> > >authenticated session.  Limiting them to the address they
>> > authenticated as
>> > >may be too strict.  Including it in the Received header is probably a
>> > more
>> > >useful option.
>> >
>> > Dear Tom,
>> >
>> > Thanks, that you understood. (Sorry, the issue is not related to
>> > Vpopmail,
>> > but may be of interest to most).
>> >
>> > Including the authenticated ID in the Received header is good, but
>> > still it
>> > would not be able to stop the menace of Spamming from your own users
>> > (who
>> > is going to monitor the logs of mails sent by users). Also, in the
>> > days of
>> > virus outbreak and users having password saved in their outlook
>> > express,
>> > the feature can be saviour.
>> >
>> > BTW, Shouguan Lin had pointed to a link
>> > 
>>
<http://night.rdslink.ro/dudu/qmail/>ht
tp://night.rdslink.ro/dudu/qmail/ 
>>
>> > with features
>> >
>> >  o   Added my own patch, that checks whether the 'mail
>> > from'
>> > value is
>> >  different from the username used for SMTP AUTH, thus
>> > preventing
>> >  source address spoofing. Useful for ISP's that only
>> > relay
>> > mails
>> >  from authenticated users.
>> >  o   The 'mail from' verification is now configurable
>> > through a
>> > knob
>> >  defined in /var/qmail/control/spoofcheck or in the
>> > environment
>> >  variable $SPOOFCHECK
>> >
>> > But, this is part of unified patch which is difficult situation for
>> > me.
>> >
>> > It's my request to Dr Erwin Hoffmann through this list that if he adds
>> > the
>> > feature into his authentication patch which is also included into the
>> > Vpopmail contrib, we all would get benefited.


>>This is problematic for ISP customers whose ISPs block outbound port 25,
>>therefor forcing relaying through their servers, but who also have a
>>vanity domain or similar provided by a third party. ISPs would then be
>>disallowing any form of sending mail with that From: field, which is
>>pretty bogus.
>>Many of these so-called anti-spam measures are approaching throwing not
>>just the baby out with the bathwater, but the entire tub.
>>Why don't I reiterate the question Jeremy Kitchen so accurately asked,
>>"What problem are you solving?". "Forged" From fields server a
>>legitimate purpose, just like doing the same in the To field can (think
>>BCC mailing lists with "Undisclosed Recipients" in the To). Yes,
>>spammers abuse this, as do virus writers.
>>I definitely recommend this "functionality" be made optional, hard to
>>turn on, and as unadvertised as possible. Those few people who know
>>they'd benefit and not suffer can then find it, and those people who
>>think they'd benefit but wouldn't realize the consequences wouldn't
>>clobber their users.
>>
>>Nick Harring
>>Webley Systems
>
>Any AntiSpamming measure onto SMTP Authenticatted mail sending has to be 
>optional like all other such means.

>Devendra Singh

technically, what you suggest can be done. However, I personally dont
believe thats the way to go; and I will certainly not add those features
into SPAMCONTROL. Let my outline my thoughts:

1. SPAMCONTROL is a patch particular suited to control SMTP traffic from
the Internet to your Intranet(s). Technically, the difference is due to the
setting of the $RELAYCLIENT environment variable.

2. SPAMCONTROL allows exhaustive logging of the SMTP traffic.

3. SPAMCONTROL provides SMTP Auth functionality - it logs all SMTP Auth
sessions with the current user name.

4. SPAMCONTROL provides - by means of the LOCALFMCHECK - some means to
control traffic from the Intranet(s) to the Internet/Intranet(s). This is
basically useful in order to pinpoint PCs with open backdoors, trojans etc.

5. Spam ist not a matter of Authentication (which is unfortunatly tried by
different approaches like SPF et al.) rather its a matter of Authorization.

6. In case you (the ISP/company) allows a user to use your SMTP gateway by
means of SMTP Authentication (with a username and password you have to
store) you have to have some level of trust to that user, and you are
Authoritive for that user since you can easly remove his particular access
rights.

7. In case the user abuses your SMTP gateway (i.e. sending out Spam emails
to the rest of the world), it is basically your responsibiltiy to prevent
that. Using SPAMCO

Re: [vchkpw] SMTP Authenticated user is able to anyone in rcpthos ts

[Devendra Singh]

At 10/06/04 19:11 (), you wrote:
On Wed, 2004-06-09 at 00:13, Devendra Singh wrote:
> At 08/06/04 11:41 (), Tom Collins wrote:
> >On Jun 7, 2004, at 9:28 PM, Devendra Singh wrote:
> >>I would like to re-frame my Subject: "SMTP Authenticated user is
> able to
> >>impersonate anyone in rcpthosts".
> >
> >You could re-frame it even more.  Authenticated SMTP users can use
> any
> >FROM address and submit mail for any host.
> >
> >Some clients may have multiple from addresses going through a single
> >authenticated session.  Limiting them to the address they
> authenticated as
> >may be too strict.  Including it in the Received header is probably a
> more
> >useful option.
>
> Dear Tom,
>
> Thanks, that you understood. (Sorry, the issue is not related to
> Vpopmail,
> but may be of interest to most).
>
> Including the authenticated ID in the Received header is good, but
> still it
> would not be able to stop the menace of Spamming from your own users
> (who
> is going to monitor the logs of mails sent by users). Also, in the
> days of
> virus outbreak and users having password saved in their outlook
> express,
> the feature can be saviour.
>
> BTW, Shouguan Lin had pointed to a link
> 
<http://night.rdslink.ro/dudu/qmail/>http://night.rdslink.ro/dudu/qmail/ 

> with features
>
>  o   Added my own patch, that checks whether the 'mail
> from'
> value is
>  different from the username used for SMTP AUTH, thus
> preventing
>  source address spoofing. Useful for ISP's that only
> relay
> mails
>  from authenticated users.
>  o   The 'mail from' verification is now configurable
> through a
> knob
>  defined in /var/qmail/control/spoofcheck or in the
> environment
>  variable $SPOOFCHECK
>
> But, this is part of unified patch which is difficult situation for
> me.
>
> It's my request to Dr Erwin Hoffmann through this list that if he adds
> the
> feature into his authentication patch which is also included into the
> Vpopmail contrib, we all would get benefited.
>
This is problematic for ISP customers whose ISPs block outbound port 25,
therefor forcing relaying through their servers, but who also have a
vanity domain or similar provided by a third party. ISPs would then be
disallowing any form of sending mail with that From: field, which is
pretty bogus.
Many of these so-called anti-spam measures are approaching throwing not
just the baby out with the bathwater, but the entire tub.
Why don't I reiterate the question Jeremy Kitchen so accurately asked,
"What problem are you solving?". "Forged" From fields server a
legitimate purpose, just like doing the same in the To field can (think
BCC mailing lists with "Undisclosed Recipients" in the To). Yes,
spammers abuse this, as do virus writers.
I definitely recommend this "functionality" be made optional, hard to
turn on, and as unadvertised as possible. Those few people who know
they'd benefit and not suffer can then find it, and those people who
think they'd benefit but wouldn't realize the consequences wouldn't
clobber their users.
Nick Harring
Webley Systems
Any AntiSpamming measure onto SMTP Authenticatted mail sending has to be 
optional like all other such means.

Devendra Singh
__
Devendra Singh
IndiaMART InterMESH Limited
(Global Gateway to Indian Market Place)
B-1, Sector 8, Noida, UP - 201301, India
EPABX : +91-120-2424945, +91-120-3094634, +91-9810646342
Fax: +91-120-2424943
http://www.indiamart.com
http://www.indiangiftsportal.com
http://www.indiantravelportal.com
__ 

Re: [vchkpw] SMTP Authenticated user is able to anyone in rcpthos ts

[Nick Harring]

Title: Re: [vchkpw] SMTP Authenticated user is able to anyone in rcpthosts





On Wed, 2004-06-09 at 00:13, Devendra Singh wrote:
> At 08/06/04 11:41 (), Tom Collins wrote:
> >On Jun 7, 2004, at 9:28 PM, Devendra Singh wrote:
> >>I would like to re-frame my Subject: "SMTP Authenticated user is
> able to 
> >>impersonate anyone in rcpthosts".
> >
> >You could re-frame it even more.  Authenticated SMTP users can use
> any 
> >FROM address and submit mail for any host.
> >
> >Some clients may have multiple from addresses going through a single 
> >authenticated session.  Limiting them to the address they
> authenticated as 
> >may be too strict.  Including it in the Received header is probably a
> more 
> >useful option.
> 
> Dear Tom,
> 
> Thanks, that you understood. (Sorry, the issue is not related to
> Vpopmail, 
> but may be of interest to most).
> 
> Including the authenticated ID in the Received header is good, but
> still it 
> would not be able to stop the menace of Spamming from your own users
> (who 
> is going to monitor the logs of mails sent by users). Also, in the
> days of 
> virus outbreak and users having password saved in their outlook
> express, 
> the feature can be saviour.
> 
> BTW, Shouguan Lin had pointed to a link 
> http://night.rdslink.ro/dudu/qmail/
> with features
> 
>  o   Added my own patch, that checks whether the 'mail
> from' 
> value is
>  different from the username used for SMTP AUTH, thus 
> preventing
>  source address spoofing. Useful for ISP's that only
> relay 
> mails
>  from authenticated users.
>  o   The 'mail from' verification is now configurable
> through a 
> knob
>  defined in /var/qmail/control/spoofcheck or in the
> environment
>  variable $SPOOFCHECK
> 
> But, this is part of unified patch which is difficult situation for
> me.
> 
> It's my request to Dr Erwin Hoffmann through this list that if he adds
> the 
> feature into his authentication patch which is also included into the 
> Vpopmail contrib, we all would get benefited.
> 
This is problematic for ISP customers whose ISPs block outbound port 25,
therefor forcing relaying through their servers, but who also have a
vanity domain or similar provided by a third party. ISPs would then be
disallowing any form of sending mail with that From: field, which is
pretty bogus. 
Many of these so-called anti-spam measures are approaching throwing not
just the baby out with the bathwater, but the entire tub.
Why don't I reiterate the question Jeremy Kitchen so accurately asked,
"What problem are you solving?". "Forged" From fields server a
legitimate purpose, just like doing the same in the To field can (think
BCC mailing lists with "Undisclosed Recipients" in the To). Yes,
spammers abuse this, as do virus writers. 
I definitely recommend this "functionality" be made optional, hard to
turn on, and as unadvertised as possible. Those few people who know
they'd benefit and not suffer can then find it, and those people who
think they'd benefit but wouldn't realize the consequences wouldn't
clobber their users.


Nick Harring
Webley Systems