source SENDER authentication ? (as opposed to SPF HOST authentication)
Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip address x.x.x.x is authorized to send mail as from domain “A”, but how about a means to confirm that ‘[EMAIL PROTECTED]’ actually is a real user before accepting mail from him ? Thanks Michael Grey
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Wed, Aug 30, 2006 at 10:10:00AM -0700, Michael Grey wrote: > I am aware of SPF which can confirm that a host at ip address x.x.x.x is > authorized to send mail as from domain "A", but how about a means to confirm > that '[EMAIL PROTECTED]' actually is a real user before accepting mail > from him ? The short answer is that there's no way to do that in general, regardless of SA, so no. -- Randomly Generated Tagline: You recoil from the crude; you tend naturally toward the exquisite. pgpd9ytY2E3x9.pgp Description: PGP signature
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On 30-Aug-06, at 1:10 PM, Michael Grey wrote:Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip address x.x.x.x is authorized to send mail as from domain “A”, but how about a means to confirm that ‘[EMAIL PROTECTED]’ actually is a real user before accepting mail from him ?I don't believe SA can do that as it's a content filter. Some MTAs can do this and this is were you want those kinds of verifications to happen, before DATA. The problem is that if you do it for every address you will get false positives, especially from sources like mailing lists, news & info subscriptions, etc., and you'll find yourself whitelisting alot. I actually do this using Postfix but I use a table of 'frequently forged domains' whose addresses are verified before they are allowed to pass on to the content filters. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
Theo Van Dinter wrote: > On Wed, Aug 30, 2006 at 10:10:00AM -0700, Michael Grey wrote: >> I am aware of SPF which can confirm that a host at ip address x.x.x.x is >> authorized to send mail as from domain "A", but how about a means to confirm >> that '[EMAIL PROTECTED]' actually is a real user before accepting mail >> from him ? > > The short answer is that there's no way to do that in general, regardless > of SA, so no. > There is a way to do it, but someone more skilled at PERL than I would have to carve it... you actually open an SMTP conversation with "REMOTE_DOMAIN.com" a la: Connected to mail.wolfstar.ca. Escape character is '^]'. 220 ext1.wolfstar.ca ESMTP Postfix (Debian/GNU) EHLO spamTest.bot 250-ext1.wolfstar.ca 250-PIPELINING 250-SIZE 10240 250-ETRN 250 8BITMIME MAIL FROM: [EMAIL PROTECTED] 250 Ok RCPT TO: [EMAIL PROTECTED] 554 <[EMAIL PROTECTED]>: Relay access denied ... trap that "5xx" return, and you know its a bogus sender. The plug-in adds 2 points to the score. Get a "250 Ok" back, and you are likely "safe"... score 0. -- --Michel Vaillancourt Wolfstar Systems www.wolfstar.ca
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
Gino Cerullo writes: > part 1.2 text/plain1027 > On 30-Aug-06, at 1:10 PM, Michael Grey wrote: > > > Are there any SA methods that allow verification of the sender of > > an email ? > > > > I am aware of SPF which can confirm that a host at ip address > > x.x.x.x is authorized to send mail as from domain A, but how > > about a means to confirm that [EMAIL PROTECTED] actually is a > > real user before accepting mail from him ? > > > I don't believe SA can do that as it's a content filter. Some MTAs > can do this and this is were you want those kinds of verifications to > happen, before DATA. The problem is that if you do it for every > address you will get false positives, especially from sources like > mailing lists, news & info subscriptions, etc., and you'll find > yourself whitelisting alot. > > I actually do this using Postfix but I use a table of 'frequently > forged domains' whose addresses are verified before they are allowed > to pass on to the content filters. It's also worth noting that doing this is counterproductive in an overall strategy sense, since it drives the spammers to simply use known-valid third-party addresses -- such as random addrs from their target address list -- as the forged source of the spam. The end result for us end users, is a massive increase in "spam blowback", which is what we've seen since those MTAs implemented it. :( --j.
RE: source SENDER authentication ? (as opposed to SPF HOST authentication)
Yes, I tend to agree with this... the reason why many POP servers reply to VRFY with 'You can try...' instead of a yes or no. Unfortunately I am not the one driving this requirement ;) I like Michel Vaillancourt's idea - if it has to be done. I appreciate everyone's feedback to this question. Michael Grey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 10:44 AM To: Gino Cerullo Cc: users@spamassassin.apache.org Subject: Re: source SENDER authentication ? (as opposed to SPF HOST authentication) Gino Cerullo writes: > part 1.2 text/plain1027 > On 30-Aug-06, at 1:10 PM, Michael Grey wrote: > > > Are there any SA methods that allow verification of the 'sender' of > > an email ? > > > > I am aware of SPF which can confirm that a host at ip address > > x.x.x.x is authorized to send mail as from domain "A", but how > > about a means to confirm that '[EMAIL PROTECTED]' actually is a > > real user before accepting mail from him ? > > > I don't believe SA can do that as it's a content filter. Some MTAs > can do this and this is were you want those kinds of verifications to > happen, before DATA. The problem is that if you do it for every > address you will get false positives, especially from sources like > mailing lists, news & info subscriptions, etc., and you'll find > yourself whitelisting alot. > > I actually do this using Postfix but I use a table of 'frequently > forged domains' whose addresses are verified before they are allowed > to pass on to the content filters. It's also worth noting that doing this is counterproductive in an overall strategy sense, since it drives the spammers to simply use known-valid third-party addresses -- such as random addrs from their target address list -- as the forged source of the spam. The end result for us end users, is a massive increase in "spam blowback", which is what we've seen since those MTAs implemented it. :( --j.
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On 30-Aug-06, at 1:44 PM, Justin Mason wrote: Gino Cerullo writes: part 1.2 text/plain1027 On 30-Aug-06, at 1:10 PM, Michael Grey wrote: Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip address x.x.x.x is authorized to send mail as from domain “A”, but how about a means to confirm that [EMAIL PROTECTED] actually is a real user before accepting mail from him ? I don't believe SA can do that as it's a content filter. Some MTAs can do this and this is were you want those kinds of verifications to happen, before DATA. The problem is that if you do it for every address you will get false positives, especially from sources like mailing lists, news & info subscriptions, etc., and you'll find yourself whitelisting alot. I actually do this using Postfix but I use a table of 'frequently forged domains' whose addresses are verified before they are allowed to pass on to the content filters. It's also worth noting that doing this is counterproductive in an overall strategy sense, since it drives the spammers to simply use known-valid third-party addresses -- such as random addrs from their target address list -- as the forged source of the spam. The end result for us end users, is a massive increase in "spam blowback", which is what we've seen since those MTAs implemented it. :( Unfortunate but SPF would prevent that as well. If everyone just used SPF, none of this would be a problem. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Wed, Aug 30, 2006 at 01:37:37PM -0400, Michel Vaillancourt wrote: > > The short answer is that there's no way to do that in general, regardless > > of SA, so no. > > There is a way to do it, but someone more skilled at PERL than I would > have to carve it... you actually open an SMTP conversation with > "REMOTE_DOMAIN.com" a la: > > RCPT TO: [EMAIL PROTECTED] > 554 <[EMAIL PROTECTED]>: Relay access denied > > ... trap that "5xx" return, and you know its a bogus sender. The > plug-in adds 2 points to the score. > Get a "250 Ok" back, and you are likely "safe"... score 0. That *may* tell you whether or not a sender is valid -- what if the server is just blocking you? What if there's a misconfiguration for a minute? What if RCPT TO works but it turns out the server would have denied you after DATA instead? What if the server is a relay which accepts all mails for a domain regardless of whether or not the downstream server will accept it? What if the email address is not a user and only receives mails (ie: spamtraps, etc.) There is no way to solve this definitively based on current protocols/etc. You can try to make assumptions with things like VRFY (most people just disable that), RCPT TO, etc, but it doesn't necessarily mean anything wrt spam. For instance, if I was going to spam people and a "sender verification" system was in use widely, I'd just start using random addresses from my list to send to other people -- if I paid attention to those that are accepted at RCPT TO, versus those that don't, then I bypass your system trivially. -- Randomly Generated Tagline: "Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM." - Klingon Programmer's Manual pgp6jI0yYqMrv.pgp Description: PGP signature
RE: source SENDER authentication ? (as opposed to SPF HOST authentication)
At 10:55 30-08-2006, Michael Grey wrote: I like Michel Vaillancourt's idea - if it has to be done. There are milters and MTAs that can do that. It's not a good idea as it can cause a denial of service. Regards, -sm
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Wed, August 30, 2006 19:37, Michel Vaillancourt wrote: > to carve it... you actually open an SMTP conversation with > ... trap that "5xx" return, and you know its a bogus sender. > The plug-in adds 2 points to the score. > Get a "250 Ok" back, and you are likely "safe"... score 0. sendmail -bv [EMAIL PROTECTED] -- "This message was sent using 100% recycled spam mails."
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Wed, August 30, 2006 19:44, Justin Mason wrote: > list -- as the forged source of the spam. The end result for us end > users, is a massive increase in "spam blowback", which is what we've > seen since those MTAs implemented it. :( spf solves that -- "This message was sent using 100% recycled spam mails."
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
Benny Pedersen writes: > On Wed, August 30, 2006 19:44, Justin Mason wrote: > > list -- as the forged source of the spam. The end result for us end > > users, is a massive increase in "spam blowback", which is what we've > > seen since those MTAs implemented it. :( > > spf solves that Well, it would, if they would restrict address lookups to IPs that pass the SPF check. This is not the case, unfortunately. --j.
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Thu, 31 Aug 2006, Benny Pedersen wrote:
> On Wed, August 30, 2006 19:37, Michel Vaillancourt wrote:
> > to carve it... you actually open an SMTP conversation with
> > ... trap that "5xx" return, and you know its a bogus sender.
> > The plug-in adds 2 points to the score.
> > Get a "250 Ok" back, and you are likely "safe"... score 0.
>
> sendmail -bv [EMAIL PROTECTED]
>
For a local recipient it may be worth something but for a remote
address all it tells you is that your mail system knows how to
find the remote host.
EG:
% /usr/sbin/sendmail -bv [EMAIL PROTECTED]
[EMAIL PROTECTED] deliverable: mailer relay, host mail-msa.icaen.uiowa.edu,
user [EMAIL PROTECTED]
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
RE: source SENDER authentication ? (as opposed to SPF HOST authentication)
On Wed, 30 Aug 2006, SM wrote:
> At 10:55 30-08-2006, Michael Grey wrote:
> >I like Michel Vaillancourt's idea - if it has to be done.
>
> There are milters and MTAs that can do that. It's not a good idea as
> it can cause a denial of service.
Also you risk getting blacklisted. When you run one of those critters
your site looks like a hacker doing dictionary attacks. IE lots of
probes with bogus names and fewer actual valid mail transfers.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
> Are there any SA methods that allow verification of the ‘sender’ of an email ? > > I am aware of SPF which can confirm that a host at ip address x.x.x.x is > authorized to send mail as from domain “A”, but how about a means to > confirm that [EMAIL PROTECTED] actually is a real user before > accepting mail from him ? Exim can do that in the ACL rules using a verify=sender clause. I use that, and a few other checks, to identify probable spam that can be rejected without bothering to pass it through SpamAssassin. (And with Exim, it is easy to do the rejection while the SMTP connection is still open.) http://www.exim.org/ Note that it doesn't actually verify whether or not the sender exists; but whether that address is likely to accept a non-delivery notice. -Pat
