Mailing List Archive

On 6-Apr-07, at 2:10 PM, dan1 wrote:

> Hello.
>
> I have an E-card customer of our site who has sent an e-mail to
> someone who's e-mail server is using SPF.
> They detected that the sender of the e-mail was not allowed to send
> an e-mail from another server (like ours). They request this user
> to send e-mails only from one of its allowed servers.
>
> This is problematic for our E-card service, as we force the
> sender's e-mail address to be coming from the one the user is
> typing. We need to do this, as it allows the recipient to directly
> answer to the sender, and also because if there is any e-mail
> problem, the problem will directly be sent to the sender and not
> our server, else the customer would never know of the problem and
> wrongly think that the e-mail was sent properly.
>
> Can some one tell me how E-cards developpers should act regarding
> that matter?
> We currently never had any forgery of a spammer who would use our
> server, and they are limited to only 10 E-cards per day and per IP
> address, so it is quite clean and already very restrictive, and we
> also check first the sender's IP for spamlists before accepting the
> e-mail, this is probably why we didn't have any problem at all with
> hackers willing to use our service.
>
> Thanks in advance for any advice.
> Daniel - Edenpics.com

This scenario is covered on the SPF web site but essentially what you
need to is configure the header of the outgoing E-card so that the
Return-Path reflects that the email is coming from your server but
the From address is of the person sending the E-card.

This way the Return-Path indicates that the E-card is coming from
your domain and passes SPF and since the From address reflects the
address of the person sending the E-card, any replies to the E-card
will be sent to the original sender.


--
Gino Cerullo

Pixel Point Studios
21 Chesham Drive
Toronto, ON M3M 1W6

416-247-7740


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Friday 06 April 2007 14:10, dan1 wrote:

> Can some one tell me how E-cards developpers should act regarding that
> matter? We currently never had any forgery of a spammer who would use our
> server, and they are limited to only 10 E-cards per day and per IP address,
> so it is quite clean and already very restrictive, and we also check first
> the sender's IP for spamlists before accepting the e-mail, this is probably
> why we didn't have any problem at all with hackers willing to use our
> service.

http://www.openspf.org/Best_Practices/Webgenerated

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

dan1 wrote:

> I have an E-card customer of our site who has sent an e-mail to
> someone who's e-mail server is using SPF.

Yes, that's an FAQ on the openspf.org site for some years now, see
http://www.openspf.org/Best_Practices/Forwarding
http://www.openspf.org/Best_Practices/Webgenerated

> They detected that the sender of the e-mail was not allowed to send an
> e-mail from another server (like ours). They request this user to send
> e-mails only from one of its allowed servers.

Working as designed for a FAIL result, you're not permitted to say
"mail from customer" if it's actually "mail from you". As I learned
yesterday even Google still has difficulties with this concept... :-|

You've to fix your setup, or you can forget all users with a FAIL
policy (all @gmx.net, just an example, there are millions)

> We need to do this

NAK, you don't. You can say From: user, Sender: you, MAIL FROM: you,
as specified in the mail standards.

> as it allows the recipient to directly answer to the sender

You are the sender. With From: user normal replies go to the user,
not you.

> if there is any e-mail problem, the problem will directly be sent
> to the sender and not our server

You are the sender. If there's a problem between the sender (you)
and the receiver, sending mail to a third party (your user) would
be a very bad plan for several reasons:

1: it's a user, users have no clue what mail problems you might
have with the receiver, maybe they block you or something
2: it's a problem between you and the receiver, and nobody is
interested to debug any potential problems between your user
and the receiver. Stick to one error on one route, don't add
more routes, let alone routes to clueless users.

> the customer would never know of the problem and wrongly think
> that the e-mail was sent properly.

You know the address of your user, if it's a very simple problem
(judged by you, because you know how stuff works) like a typo in
the receiver address you can inform your customer.

If it's the usual tricky case, you're blocked by the receiver or
similar, informing the user is stil possible, but above all you
have to fix it, your user can't (and won't understand the issue)

> Can some one tell me how E-cards developpers should act regarding
> that matter?

Check out the links noted above. There's a "help" mailing list
better suited to work out the SPF basics than this list, with a
huge archive, see http://dir.gmane.org/gmane.mail.spam.spf.help

There's also a chapter in RFC 4408 about this kind of mail service:
http://tools.ietf.org/html/rfc4408#section-9.4

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Fri, 6 Apr 2007, william(at)elan.net wrote:

> you implimnent it, I'd suggest that instead of using BASE16 it be done
> as BASE32 (but not BASE64 since email address is not case-sensetive)
> and timestamp id could be smaller in BASE32 as well.

Actually, localpart is *supposed* to be case *preserving* according to
rfc2821. Systems may or may not be case sensitive for their own mailboxes, but
they should never alter the case in the localpart. There are some super
braindead systems out there, however, that smash case in the localpart.

I've gone back and forth. When signing/fowarding with SRS the sig is base64.
Sometimes I just block bounces with smashed case - if the MTA is that
braindead, the bounce probably isn't useful. But if you really want
the bounces (e.g. to blacklist the original sender that I've coded in
there ;-), then you have accept a case-insensitive match of the sig.

The domain part, OTOH, is not case sensitive.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

The ecard services need to start using their own email address in MAIL
FROM. If that is not done they are indistiguishable from forgery (in
fact that is exactly what they do basically) and it is not just SPF but
eveyr other email authentication proposal has problems with that.

To deal with bounces, e-card service should have bounce handler that
based on some id of original email can verify that its for one of their
customers and forward it to further as appropriate. My recommendation
for developers of such service is to have a database with ids for all
users of their service and put hash (unique id + timestamp) as part of
MAIL FROM address (this is SRS/SES-like service basically), i.e. here is
an example:

FROM:<eba=69e9db9ba8fab99552c25fcea6fcaf69=0406071307=1225@ecard.example>

Above 1225 is database id that you can correspond to william@elan.net,
0406071307 is a timestamp and the rest is md5(email timestamp). Your
system can then verify that received bounce is not too long ago and
if so process this bounce (remeber to check SPF on where bounce came
from and have SPF record for ecard.example as well). Note that if
you implimnent it, I'd suggest that instead of using BASE16 it be done
as BASE32 (but not BASE64 since email address is not case-sensetive)
and timestamp id could be smaller in BASE32 as well.

Even simpler if you have database for each and every email sent through
ecard service, then you just do FROM:<123353422@ecard.example> where
'123343422' is the the id you lookup in your database to find where
to forward email to and when the email was originally sent.

On Fri, 6 Apr 2007, dan1 wrote:

> Hello.
>
> I have an E-card customer of our site who has sent an e-mail to someone who's e-mail server is using SPF.
> They detected that the sender of the e-mail was not allowed to send an e-mail from another server (like ours). They request this user to send e-mails only from one of its allowed servers.
>
> This is problematic for our E-card service, as we force the sender's e-mail address to be coming from the one the user is typing. We need to do this, as it allows the recipient to directly answer to the sender, and also because if there is any e-mail problem, the problem will directly be sent to the sender and not our server, else the customer would never know of the problem and wrongly think that the e-mail was sent properly.
>
> Can some one tell me how E-cards developpers should act regarding that matter?
> We currently never had any forgery of a spammer who would use our server, and they are limited to only 10 E-cards per day and per IP address, so it is quite clean and already very restrictive, and we also check first the sender's IP for spamlists before accepting the e-mail, this is probably why we didn't have any problem at all with hackers willing to use our service.
>
> Thanks in advance for any advice.
> Daniel - Edenpics.com
>
> -------
> Sender Policy Framework: http://www.openspf.org/
> Archives at http://archives.listbox.com/spf-discuss/current/
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?list_id=735

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Hello, guys.

Thank you very much for your answers to all.
Now I understand what I must do and I am changing our ecard system code.
I am confident that it will work this way.

Thanks again and best regards,
Daniel - www.Edenpics.com


----- Original Message -----
From: "Frank Ellermann" <nobody@xyzzy.claranet.de>
To: <spf-discuss@v2.listbox.com>
Sent: Friday, April 06, 2007 10:24 PM
Subject: [spf-discuss] Re: SPF blocking e-mails coming from an E-card
service server


> dan1 wrote:
>
>> I have an E-card customer of our site who has sent an e-mail to
>> someone who's e-mail server is using SPF.
>
> Yes, that's an FAQ on the openspf.org site for some years now, see
> http://www.openspf.org/Best_Practices/Forwarding
> http://www.openspf.org/Best_Practices/Webgenerated
>
>> They detected that the sender of the e-mail was not allowed to send an
>> e-mail from another server (like ours). They request this user to send
>> e-mails only from one of its allowed servers.
>
> Working as designed for a FAIL result, you're not permitted to say
> "mail from customer" if it's actually "mail from you". As I learned
> yesterday even Google still has difficulties with this concept... :-|
>
> You've to fix your setup, or you can forget all users with a FAIL
> policy (all @gmx.net, just an example, there are millions)
>
>> We need to do this
>
> NAK, you don't. You can say From: user, Sender: you, MAIL FROM: you,
> as specified in the mail standards.
>
>> as it allows the recipient to directly answer to the sender
>
> You are the sender. With From: user normal replies go to the user,
> not you.
>
>> if there is any e-mail problem, the problem will directly be sent
>> to the sender and not our server
>
> You are the sender. If there's a problem between the sender (you)
> and the receiver, sending mail to a third party (your user) would
> be a very bad plan for several reasons:
>
> 1: it's a user, users have no clue what mail problems you might
> have with the receiver, maybe they block you or something
> 2: it's a problem between you and the receiver, and nobody is
> interested to debug any potential problems between your user
> and the receiver. Stick to one error on one route, don't add
> more routes, let alone routes to clueless users.
>
>> the customer would never know of the problem and wrongly think
>> that the e-mail was sent properly.
>
> You know the address of your user, if it's a very simple problem
> (judged by you, because you know how stuff works) like a typo in
> the receiver address you can inform your customer.
>
> If it's the usual tricky case, you're blocked by the receiver or
> similar, informing the user is stil possible, but above all you
> have to fix it, your user can't (and won't understand the issue)
>
>> Can some one tell me how E-cards developpers should act regarding
>> that matter?
>
> Check out the links noted above. There's a "help" mailing list
> better suited to work out the SPF basics than this list, with a
> huge archive, see http://dir.gmane.org/gmane.mail.spam.spf.help
>
> There's also a chapter in RFC 4408 about this kind of mail service:
> http://tools.ietf.org/html/rfc4408#section-9.4
>
> Frank
>
>
> -------
> Sender Policy Framework: http://www.openspf.org/
> Archives at http://archives.listbox.com/spf-discuss/current/
> To unsubscribe, change your address, or temporarily deactivate your
> subscription,
> please go to http://v2.listbox.com/member/?list_id=735

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735