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
>> > 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
>>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.
>Any AntiSpamming measure onto SMTP Authenticatted mail sending has to be
>optional like all other such means.
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
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 SPAMCONTROL (and ie. my newanalyse) you can check the
qmail-smtpd logs and in case of lets say a contract violation, you can
disable the user.
8. However, enforcing technical limits how to use SMTP Authentication, in
addition enforce username = local part of the Mail From: address is not
entitled my any RFC or other reasoning.
Pls. refrain from aggrevate the common understanding of SMTP traffic.
If you have a particular problem with your customers, try to solve this by
your own in the fist place; its certainly not a matter of the community.
However, you are free to incorportate all neccessary changes to the the
open source software.
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24